Application hangs when using onWidgetDraw

[phuhl]

I condensed my problem down to the code in this repository. Essentially you have to start the application and quickly scroll up and down in the upcoming window. After a few seconds the application hangs. I am not sure whether this is a gtk bug or a haskell-gi bug, nevertheless i report it here first.

I also asked this as a question on Stackoverflow.

[garetxe]

Thanks for the report! I can reproduce the hang on my computer, I will let you know as soon as I find something.

[garetxe]

I have been looking into this, I think I am starting to see what it going on.

First of all, at least in my computer, your test case does not hang if I remove -threaded from the ghc options listed in the cabal file (could you please check that this is also true for you?). This suggests that it is some race condition.

The way signal handlers work in haskell-gi is that we take a reference to the arguments passed to the signal handler when constructing the Haskell wrappers, and remove the reference when the haskell runtime releases the object during garbage collection.

Unfortunately, when running code compiled with -threaded, the GC may run in a different OS thread than the ui thread, so we drop the reference in a thread which is not the one that called our callback.

To test this, I modified the onWidgetDraw handler to unref the pointer after calling the callback, without waiting for the GC. Doing this I cannot reproduce the crash.

So I have a very strong suspicion that the bug is due to cairo getting very confused when one thread allocates a cairo_t context, and another one unrefs it. I don't understand exactly what goes wrong, but the cairo lib makes extensive use of thread-local storage, so a problem here seems likely.

What I still don't see is how to fix this, I will try to see how other language bindings deal with this.

[phuhl]

Thank you for looking into this. I can confirm, it does not hang without -threaded. I did suspect that GC might be part of the problem but i did not have enough in depth knowledge to verify this.

[garetxe]

Thanks for the confirmation. Just to make sure that I understood what was happening here, I wrote the C program in https://gist.github.com/garetxe/54b63ae8098c8b934be54c89eed73594 that simulates what the Haskell GC does when using the threaded runtime, and it also hangs, as expected.

Interestingly, for me at least the hang only occurs when running under X, under Wayland I cannot reproduce the crash. So it is probably due to some thread unsafe behavior in the Xlib backend of cairo. (In fact, the hang is actually due to an XError when running under X, in _cairo_xlib_surface_finish, as you can check .)

I also have an idea for how to fix this (which should also fix #97, and a number of other infelicities with memory allocation), but it involves a bit of a redesign of some internals of haskell-gi.

[garetxe]

Thanks again for the report, and sorry that this took so long to fix... It should now be fixed in 00367c5, please let me know (and feel free to reopen the issue) if that doesn't fix the issue for you.