[plt-scheme] mred + OpenGL crashes

From: Dave Griffiths (dave at pawfal.org)
Date: Tue Jan 23 04:55:13 EST 2007

> At Mon, 22 Jan 2007 21:32:49 +0000, dave wrote:
>> I have some questions about OpenGL use in mred, I'm new to PLT, so
>> hopefully this is something I've overlooked or I'm being silly. I'm
>> running version 352 on linux (ubuntu breezy), but I get reports of the
>> same problems on OSX too.
> I'm not aware of any OpenGL problems on Mac OS X, but definitely report
> bugs.
> I don't use OpenGL in MrEd a lot myself, but I use it occasionally
> (usually under Mac OS X, but sometimes on Windows or Linux), and I can
> run the OpenGL examples multiple times in DrScheme.

Interesting, thanks for checking. Do you have to manually close the window
first, or does it shutdown and reopen when you restart the example?

> In the case of Linux, we've had reports of problems, but we've also had
> trouble distinguishing between MrEd bugs and OpenGL-driver bugs. We've
> certainly run into OpenGL problems where upgrading or replacing the
> driver fixed the problem (even with popular Linux distributions). But
> others cases have been less clear, and usually the problem is that
> things work ok on the hardware that I have access to. So, again, bug
> reports are welcome.

That is always the hard distinction, but I doubt it's driver issues as
these examples aren't doing particually obscure things with OpenGL. I'll
file a bug report, and leave it at that as I'm mainly concerned about the
other issues atm.

>> The reason for this is that I have also embedded mzscheme into a glut
>> application, and I had similar (although not quite so severe) problems.
>> I tracked this down to the fact I was calling load-extension after
>> initialising and setting up the glut window. Putting the load-extension
>> call before any other OpenGL related setup fixed the problem completely.
>> Presumably this is a dlopen linking order issue, maybe there are linking
>> flags I need to set?
> Was it that libraries used by OpenGL were introducing bindings that
> shadow others used by your extension? Maybe C-library version
> mismatches, or something about initializing OS-level threads? Or was it
> a memory-management problem that happened to show up with different
> load orders?

Well the latter does look increasingly likely, as the crashes all occur
inside STL allocation code iirc. Trying to replicate them with malloc or
new doesn't seem to have the same problems. I built plt from source (with
--enable-shared), is there some way the C++ libraries used could be
mismatched? Does mzscheme use STL?

> ".mredrc" is certainly loaded after the windowing system is
> initialized. Short of re-linking MrEd, I can think of a way to load an
> extension earlier.

I'm tempted to try patching mred to load .meredrc first, but I'm now
thinking this is fixing the symptom rather than the cause.

I'll see if I can take OpenGL out of the equation, and post some code to
replicate the bug.



Posted on the users mailing list.