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?

Second workaround so far:
Use something like that:

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

with

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

That's strange.

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.