GameWindow() Crashing in SVN on Linux

Thanks for the report. Actually I am fighting with this problem right now and it's good to know it's not only a problem on my configuration.

The control flow has changed a lot since 0.9.0 - in SVN it works like this:

1. Open a display connection and query available visuals and select the one matching the user's request (GraphicsMode class).
2. Query available monitors with xrandr (optional -- DisplayDevice class).
3. Create the GameWindow/GLControl with the visual selected above. GameWindows are created on their own display connection, while GLControls on the one opened by Windows.Forms.
4. Create the context and attach it to the window.
5. Dispose() -- the window is closed and the context is destroyed.
6. Alternatively: the finalizer is ran and the window is destroyed *from a different thread*.

I'm no xlib expert, but I think I can there are two issues at play here:

1. Failing Glx.CreateContext: I *think* this has to do with the display connection being invalid. Documentation is somewhat sparse (can you query/create a visual in one connection and use it in another?), so it's mostly a matter of educated guesses.
2. Failing Glx.MakeCurrent on shutdown. I think I've discovered the cause (a moment of clarity while commuting to work :) ) - the finalizer thread is called on a different thread, which *may* cause problems (once more, docs are somewhat sparse).

If you have any ideas I'd love to hear them! I consider this a blocking issue for 0.9.1 (which will be released shortly after this is resolved). :)

I have made some potential fixes to GameWindow/X11, and it no longer crashes on Mesa3d/software (I still see intermittent crashes on Ati/fglrx).

Can you please checkout and test if it still crashes?

Thanks :)

Thanks, this sheds some light to what is happening.

Your analysis looks solid: the context is not destroyed at the correct time, which causes problems when creating a new one (the new one is added before the first one is removed from the list of contexts).

Edit: I am not able to reproduce the exception. Here, it completes the stress test without issue:

for (int i = 0; i < 100; i++)
{
     GameWindow gw = new GameWindow(/*640, 480, GraphicsMode.Default*/);
     gw.Dispose();
     gw = null;
     Console.WriteLine("Finished {0}", i);
     GC.Collect(2);
     Console.WriteLine("Collected {0}", i);
}

It does crash if I remove the call to gw.Dispose() however. Investigating...

Edit 2:
I've updated GameWindow to throw an ObjectDisposedException in this case:

window.Dispose()
window.Context.Dispose()

The first line disposes the context internally. I'm still not able to reproduce the problem...

Edit 3:
I can reproduce the exception only if I do *not* call gw.Dispose(). This means the problem lies in the GraphicsContext finalizer.

Edit 4:
Ok, what happens if you replace this line:

GC.Collect(2);

with this?

GC.Collect(2);
GC.WaitForPendingFinalizers();
GC.Collect(2);

Edit 5 (and final :)):
Ok, there are two solutions for all these problems (from the perspective of OpenTK):

1. Make sure all X11 calls occur in one thread. Due to the nature of OpenTK this is close to impossible (e.g. the user can simply do: new Thread().Start(GameWindow.Run); and blow everything up).

Initialize X11 in multithreaded mode with XInitThreads.

I am going for the second approach, and indeed it looks like the race conditions are alleviated (stress tests completes succesfully). There's a *lot* of work to do before OpenTK becomes trully thread safe, but thankfully this can be introduced gradually - not many users are going to create/destroy 100 GameWindows :)

Oops yes. Just commited.