Mysterious deadlock (with X11 connection)

#1

I am getting some mysterious deadlock. At some point with certain behavior, my GUI program just… freezes.

It seems like most debugging guide for deadlock involves dealing with the convenient exception kindly thrown by GHC. In my case, it seems to fail with detecting it.
Plus, I cannot profile using -p since it even does not close properly by single ctrl+c!
(Well to be fair, ctrl+c does not work even before deadlock. Is it supposed to be like this?)

How do I proceed from here for debugging? I’ve tried removing all blocking code I know of. (Perhaps again, might be caused by some code from library dependency)

EDIT1: Forked a thread which logs every 1 second. The moment the program stops, the log stops as well - even though it should be distinct, unrelated thread. Mysterious.

#2

Is there any chance we could have a look at your program?

1 Like
#3

Simple stuff: are you building in threaded mode ?

Try adding more fine grained logging to narrow down when things go wrong ?

1 Like
#4

Let me upload the code when i get back to computer.

I am sure I am building in threaded mode. But let me check again.

How fine-grained does it need to be? It is multi-threaded and each thread would have been stopped somewhere distinct.

EDIT: Basically it is stuck here: WMStatus-L160
Seems like invalid X11 query is causing some weird issues…

EDIT2: Found that the call involves ccall unsafe. So entire process hanging is expected (just did a bit more reading, it should not. I should be running X11 on separate capability…).
Wonder why Xlib hangs, though.

1 Like
#5

Turns out it was running on the same capability. Duh…
(EDIT: Fixed # of capabilities issue, my dumb mistake)

Why is FFI so hard?

EDIT: It seems like when there are more capabilities, X handling thread could go on for a few more requests and then halts. I don’t get what is happening with this.

EDIT2: Turns out a library’s “safe” X call is interfering in unknown way, meh.

1 Like