[plt-scheme] mred + OpenGL crashes

> > 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?

I don't have to close the window first. It works either way.

> > 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.

But MrEd juggles GL contexts in a slightly unusual way, I think. I'm
slowing remembering...

I think most GL programs just set a GL context and stick with it. MrEd
may change the context so that different MzScheme-level threads can use
different contexts. Of course, as long as a group of GL commands are
run within a `with-gl-context', they're kept together, but the GL
context can change between `with-gl-context' calls.

I forget the details, but I think the context can change even if
there's only one GL context in use, just in case GL calls are used
outside of a `with-gl-context'.

> >> 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?

MzScheme and MrEd don't use STL.

But MrEd does define the C++ `new' operator to be a GC allocation. I
forgot about this, because I'd already changed Mac OS X (Aqua only) to
get rid of the definition.

I've removed the definition of `new' from MrEd for X11 builds in SVN. I
don't know whether this change will fix the problem you're having with
MrEd (it wouldn't explain the problem for embedding MzScheme), but it's
a good long-term change, anyway.

Matthew