www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - DerelictGL3 reload crashes in 32 builds

reply Igor <stojkovic.igor gmail.com> writes:
In 64 bit builds it works with both LDC and DMD but in 32 bit LDC 
version crashes and DMD release version crashes. Using LDC debug 
build I managed to find that it crashes after executing ret 
instruction from bindGLFunc in glloader. If someone wants to try 
it you can do it with this project: 
https://github.com/igor84/dngin. I was testing this from Visual 
Studio but dub 32 bit LDC build also crashed.

Am I doing something wrong or is this some known DerelictGL3 or 
compiler issue?
Aug 20 2017
parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 20 August 2017 at 19:29:55 UTC, Igor wrote:
 In 64 bit builds it works with both LDC and DMD but in 32 bit 
 LDC version crashes and DMD release version crashes. Using LDC 
 debug build I managed to find that it crashes after executing 
 ret instruction from bindGLFunc in glloader. If someone wants 
 to try it you can do it with this project: 
 https://github.com/igor84/dngin. I was testing this from Visual 
 Studio but dub 32 bit LDC build also crashed.

 Am I doing something wrong or is this some known DerelictGL3 or 
 compiler issue?
This is a known issue [1] that I'm currently trying to resolve. I hadn't yet tested it using free functions (the bug report uses context types), so this new information helps. [1] https://github.com/DerelictOrg/DerelictGL3/issues/56
Aug 20 2017
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 21 August 2017 at 02:40:59 UTC, Mike Parker wrote:
 On Sunday, 20 August 2017 at 19:29:55 UTC, Igor wrote:
 In 64 bit builds it works with both LDC and DMD but in 32 bit 
 LDC version crashes and DMD release version crashes. Using LDC 
 debug build I managed to find that it crashes after executing 
 ret instruction from bindGLFunc in glloader. If someone wants 
 to try it you can do it with this project: 
 https://github.com/igor84/dngin. I was testing this from 
 Visual Studio but dub 32 bit LDC build also crashed.

 Am I doing something wrong or is this some known DerelictGL3 
 or compiler issue?
This is a known issue [1] that I'm currently trying to resolve. I hadn't yet tested it using free functions (the bug report uses context types), so this new information helps. [1] https://github.com/DerelictOrg/DerelictGL3/issues/56
I'm unable to reproduce this locally using my little test app. It only crashes for me in 32-bit when using context objects. I also took your winmain.d module, modified it to compile with `dub --single`, then compiled and executed it with both the default architecture (-m32) and -m32mscoff (via dub's -ax86_mscoff command line argument). In both cases it compiled executed just fine. Have you tried to compile outside of VisualD?
Aug 21 2017
parent reply Igor <stojkovic.igor gmail.com> writes:
On Monday, 21 August 2017 at 12:38:28 UTC, Mike Parker wrote:
 On Monday, 21 August 2017 at 02:40:59 UTC, Mike Parker wrote:
 On Sunday, 20 August 2017 at 19:29:55 UTC, Igor wrote:
 In 64 bit builds it works with both LDC and DMD but in 32 bit 
 LDC version crashes and DMD release version crashes. Using 
 LDC debug build I managed to find that it crashes after 
 executing ret instruction from bindGLFunc in glloader. If 
 someone wants to try it you can do it with this project: 
 https://github.com/igor84/dngin. I was testing this from 
 Visual Studio but dub 32 bit LDC build also crashed.

 Am I doing something wrong or is this some known DerelictGL3 
 or compiler issue?
This is a known issue [1] that I'm currently trying to resolve. I hadn't yet tested it using free functions (the bug report uses context types), so this new information helps. [1] https://github.com/DerelictOrg/DerelictGL3/issues/56
I'm unable to reproduce this locally using my little test app. It only crashes for me in 32-bit when using context objects. I also took your winmain.d module, modified it to compile with `dub --single`, then compiled and executed it with both the default architecture (-m32) and -m32mscoff (via dub's -ax86_mscoff command line argument). In both cases it compiled executed just fine. Have you tried to compile outside of VisualD?
Hmmm... I though I tried running with just typing dub which should use m32 by default as far as I know and got the error. I will check one more time this evening. But LDC 32bit builds crash for sure. Note that I committed a version last night where I commented out the Derelict.reload call, so just make sure it is not commented before trying it out. In the meantime can you tell me these two things: 1. How come DerelictGLES only has: static if( Derelict_OS_Windows ) ... else static if( Derelict_OS_Posix && !Derelict_OS_Mac )... when GLES is primarily intended for mobile platforms as far as I know. What should I use for Android then? 2. I see that DerelictGL3 used to have wglext.d file where wglSwapIntervalEXT was loaded. How can I get access to this function now since I can't find it anywhere in the latest version?
Aug 22 2017
next sibling parent reply Igor <stojkovic.igor gmail.com> writes:
On Tuesday, 22 August 2017 at 12:03:18 UTC, Igor wrote:
 On Monday, 21 August 2017 at 12:38:28 UTC, Mike Parker wrote:
 Have you tried to compile outside of VisualD?
Hmmm... I though I tried running with just typing dub which should use m32 by default as far as I know and got the error. I will check one more time this evening. But LDC 32bit builds crash for sure. Note that I committed a version last night where I commented out the Derelict.reload call, so just make sure it is not commented before trying it out.
I must have remembered it wrong. I just tried it again and DMD 32bit debug build works. It is DMD 32bit release build that is not working. When I run dub --build=release --force I get: ... Error object.Error (0): Access Violation ---------------- 0x59BED731 0x5A6202C9 in wglGetProcAddress 0x004103B6 0x0040DC80 0x0040C691 Program exited with code 1
Aug 22 2017
parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 22 August 2017 at 16:54:24 UTC, Igor wrote:
 On Tuesday, 22 August 2017 at 12:03:18 UTC, Igor wrote:
 On Monday, 21 August 2017 at 12:38:28 UTC, Mike Parker wrote:
 Have you tried to compile outside of VisualD?
Hmmm... I though I tried running with just typing dub which should use m32 by default as far as I know and got the error. I will check one more time this evening. But LDC 32bit builds crash for sure. Note that I committed a version last night where I commented out the Derelict.reload call, so just make sure it is not commented before trying it out.
I must have remembered it wrong. I just tried it again and DMD 32bit debug build works. It is DMD 32bit release build that is not working. When I run dub --build=release --force I get: ... Error object.Error (0): Access Violation ---------------- 0x59BED731 0x5A6202C9 in wglGetProcAddress 0x004103B6 0x0040DC80 0x0040C691 Program exited with code 1
Apologies. Between the time I read your initial post and the time I tried to reproduce the issue, the fact that you explicitly mentioned it happens in release builds slipped my mind. I'm able to reproduce this. I've add a link to this thread in the issue report linked above. Please put future comments there. I'll set some time aside on Friday to see if I can sort this out. Thanks!
Aug 23 2017
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 22 August 2017 at 12:03:18 UTC, Igor wrote:

 In the meantime can you tell me these two things:

 1. How come DerelictGLES only has:
 static if( Derelict_OS_Windows ) ...
 else static if( Derelict_OS_Posix && !Derelict_OS_Mac )...
 when GLES is primarily intended for mobile platforms as far as 
 I know. What should I use for Android then?
I'm not sure what you're referring to. There are a few static if(Derelict_OS_Android) blocks in there as well. That said, DerelictGLES is nowhere near ready for primetime. If you check the release list, there has been precisely one release: 0.0.1 in July 2015, when I first added Windows support. Since then, I've made one commit to fix a bug. The problem is the person who was the original maintainer hasn't been around in quite some time, I don't use OpenGL ES, and I've never touched the Android Developer Kit. The binding isn't even up to date with the latest DerelictUtil. The Windows and Linux should both be working, buggy perhaps but usable. It's my intention to get it updated to the latest DerelictUtil at some point and test it across ANGLE, the AMD developer kit, and other implementations that exist, including MoltenGL on OS X. However, it is not a priority for me at all right now. Moreover, it's unlikely I'll ever touch the Android bits. I'm happy to add anyone to DerelictOrg who is willing to take on the task of DerelictGLES maintenance.
 2. I see that DerelictGL3 used to have wglext.d file where 
 wglSwapIntervalEXT was loaded. How can I get access to this 
 function now since I can't find it anywhere in the latest 
 version?
Before I bring 2.0 out of beta, I will add support for platform-specific extensions via the existing mixin infrastructure. I'll also most likely add support for mixing in and loading the system API functions to completely eliminate the current link-time dependency for those who choose to use them.
Aug 23 2017
parent Igor <stojkovic.igor gmail.com> writes:
On Wednesday, 23 August 2017 at 12:59:38 UTC, Mike Parker wrote:
 On Tuesday, 22 August 2017 at 12:03:18 UTC, Igor wrote:

 [...]
I'm not sure what you're referring to. There are a few static if(Derelict_OS_Android) blocks in there as well. [...]
Ok Mike. Thanks for the info. If I learn anything new about the issue I will post it to the github.
Aug 23 2017