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

I think that is what I'd expect - in fact I guess it should be considered
an error to call gl functions outside of a with-gl-context?

The only thing I'm not sure about is calling opengl from different threads
(even using different contexts) I wasn't under the impression that the
drivers were generally reentrant.

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

That sounds very promising - I'll give it a go. The embedding issue was
one repeatable crash, whereas running in MrEd causes all sorts of problems
in random parts of code.

Many thanks,

dave