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