It's the job of the operating system to ensure that there isn't ;)
configure: checking for OS configure: result: no :) thanks for reminding me that the side-effects of this bug shouldn't persist on a normal system - sometimes I just take this old system too seriously. w98 is not exactly famous for protecting different processes from each other's problems.
If that doesn't work when the OS is doing it implicitly, there's no reason to believe that it would work if the application did it explicitly.
as I mentioned, gdb succeeds on that account, against all reason ;) it is nice that gdb managed to provide the protection usually included in an OS, and I wondered whether HOpenGL could offer the same service. perhaps it isn't worth it, and that part of the problem will die out with w98, but I thought I'd point out the opportunity.
.. driver bugs vs library bugs
appart from the driver/os issue, there does seem to be a library bug in HOpenGL. the C-version of tess exhibits the same symptoms & stack trace, and the fix is simply to add a stdcall attribute to the callback type. So, it seems that HOpenGL on windows/mingw should declare and use the GLU callbacks as stdcall, not ccall (or perhaps use APIENTRY, defined in gl.h?). But I could be wrong about this.. Cheers, Claus In some more detail: from Graphics.Rendering.OpenGL.GLU.Tesselation.hs, an example callback: type BeginCallback' = GLenum -> IO () withBeginCallback :: TessellatorObj -> BeginCallback -> IO a -> IO a withBeginCallback tessObj beginCallback action = bracket (makeBeginCallback (beginCallback . unmarshalPrimitiveMode)) freeHaskellFunPtr $ \callbackPtr -> do setBeginCallback tessObj (marshalTessCallback TessBegin) callbackPtr action foreign import ccall "wrapper" makeBeginCallback :: BeginCallback' -> IO (FunPtr BeginCallback') foreign import CALLCONV unsafe "gluTessCallback" setBeginCallback :: TessellatorObj -> GLenum -> FunPtr BeginCallback' -> IO () the ccall wrapper looks suspicious to me (btw, where is CALLCONV defined?). FunPtr (via Base.Foreign.Ptr.hs) leads to Base.GHC.Ptr.lhs, which defines: -- Function pointers for the default calling convention. data FunPtr a = FunPtr Addr# deriving (Eq, Ord) I'm not sure where to find the details of mapping between this Haskell type and its C equivalent, but if I look in my ghc-installation, I find a file include/HsFFI.h, which defines: typedef void (*HsFunPtr)(void); /* this should better match StgAddr */ This looks precisely like the callback-type that leads the C-version of tess to segfault, because the expected type for GLU callbacks happens to be, from the ghc installation, include/mingw/GL/glu.h: typedef void (APIENTRY *_GLUfuncptr)(); where APIENTRY is defined in include/mingw/GL/gl.h as: #if !defined(APIENTRY) # if defined(__WIN32__) # define APIENTRY __stdcall # else # define APIENTRY # endif #endif Which seems to be the MS version of the gcc variant I tested with tess.c, both variants meaning "callee cleans stack": # define CALLBACK __attribute__ ((__stdcall__)) void CALLBACK beginCallback(GLenum which) Note that, if I understand the "wrapper" idea correctly, HOpenGL requests the callback to be exported as using ccall convention instead.