• Namespace (13/13) Jun 26 2013 Since I had a problem by using derelict3 (more precise: I get an
• Namespace (12/12) Jun 26 2013 Second workaround so far:
• Mike Parker (10/12) Jun 26 2013 That's not exactly what I was getting at. The problem isn't with

"Namespace" <rswhite4 googlemail.com> writes:

Since I had a problem by using derelict3 (more precise: I get an 
Access Violation), Mike Parker and I were looking for the 
problem. Today Mike Parker figured out that it happens only if 
scope(exit) is used in combination with glPopAttrib. But because 
we have not much experience in reading assembly, and I (and maybe 
he also) have no good debugger, I like to ask for help to find 
and reduce the bug.

The regarding post with the example code is here: 
http://dblog.aldacron.net/forum/index.php?topic=832.msg1011#msg1011

If you write the scope(exit) glPopAttrib(mask); without the scope 
statement and move it to the end of the function everything works 
fine. But IMO it should work also with scope(exit).
Thoughts?

"Namespace" <rswhite4 googlemail.com> writes:

Second workaround so far:
Use something like that:

----
scope(exit) glAvoidAE(glPopAttrib(mask));
----

with

----
void glAvoidAE(lazy void Func) {
	Func();
}
----

That's strange.

"Mike Parker" <aldacron gmail.com> writes:

On Wednesday, 26 June 2013 at 07:55:29 UTC, Namespace wrote:
 Today Mike Parker figured out that it happens only if 
 scope(exit) is used in combination with glPopAttrib. But

That's not exactly what I was getting at. The problem isn't with 
scope(exit) or, I believe, glPopAttrib. It just so happens that 
the way your test case was set up, that particular line was the 
last to be executed before going back up the callstack to exit 
the app. Adding a writeln statement within that scope(exit) block 
caused the access violation to appear somewhere else (which 
happened to also be a scope(exit) glPopAttrib in another 
function). Adding a writeln there shifted it into the Windows 
kernel. This is a classic sign of a memory corruption bug.