Michael Vance wrote:
>
> If you happen to register an atexit() handler in your code that calls
> glXDestroyContext(), and then you create a context, FX-Mesa will then
> register an atexit() handler itself. When your program exits, the
> FX-Mesa handler is called first, it brute force deletes the context,
> and then your call in glXDestroyContext() causes memory corruption
> because it doesn't know that the context has been freed already. This
> is bad.
>
> It would seem the trivial solution is to guard the actual deletion in
> fxMesaDestroyContext() with an if( glbTotNumCtx ) { } after the ref
> count decrement. I can submit a patch to do this if necessary.
Strictly speaking, the FX driver shouldn't be in the business of
catching signals and registering atexit() handlers. However, they're
there to solve other problems.
I'm not sure that testing glbTotNumCtx is the "right" thing to do.
Perhaps all the contexts we made should be kept in a list. When
we delete a context remove it from the list, but only after checking
that the context is in fact in the list.
How does that sound?
> Also, is it just me or is the glbTotNumCtx=1 line in cleangraphics() a
> little unsafe? Does the FX driver implicitly reject the notion of
> multiple contexts?
The FX driver when used with traditional/stand-alone Mesa wasn't
intended to handle multiple contexts (full-screen mode implies one
context) but it often does work. When the FX driver is used within
the DRI framework multiple contexts are supposed to work as expected.
-Brian
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
