Opening multiple terminator windows and closing prevents more from being opened |
|||
Issue descriptionInstall terminator and then open the application, and then from within that terminal window run terminator again, which opens another window. Then close both windows. At that point you won't be able to open another terminator window and there is a terminator process still running. Other variants of this likely cause the problem too, but this reproduced it the best. Attaching to the remaining terminator process with gdb yielded a stack trace like so: pthread_cond_wait wl_display_read_events wl_display_dispatch_queue wl_display_roundtrip_queue gdk_flush gdk_main Comment from reveman@ about this: You should be able to trace that wayland round-trip going through sommelier. Note that the round-trip is asynchronous inside sommelier as that's needed to maintain correct event ordering. However, I can't think of a reason for why this would cause the round-trip to not complete.
,
Nov 7
This doesn't even require launching multiple instances of terminator. Just launch it, close it over and over and it'll happen. It must be some kind of race condition somewhere. I'll track down what's happening in sommelier. (This one looks like a good learning opportunity for the sommelier internals)
,
Nov 14
I dug into this pretty deep and had some interesting finds...in the end I believe this is actually a bug in GTK+ although I don't really have the time to track it down specifically. This issue never happens if you do 'sommelier terminator' (but you also can't close a terminator window with Ctrl+D in that mode, you have to click the X with a mouse). To reproduce the problem, I had to run terminator and close it with Ctrl+d and it would happen about half the time. I instrumented the wayland client library and added logging to it to track down what was really happening. When it hangs on exit, it's calling wl_display_prepare_read (which invokes wl_display_prepare_read_queue on the default queue) and then NOT calling wl_display_cancel_read or wl_display_read_events right after it (and the contract for wl_display_prepare_read_queue says one of those two must be called afterwards). Instead it's invoking wl_display_roundtrip after the call to wl_display_prepare_read_queue (and wl_display_prepare_read_queue returns 0). This then causes a hang when the wl_display_roundtrip call gets into wl_display_read_events because it thinks another thread has called wl_display_prepare_read_queue and is waiting on that other thread to process the events (and this app is single threaded, I only ever see one thread ID entering the wayland code). I didn't find anything in the version history for GTK to indicate this is fixed; but I can't reproduce this problem on my workstation that has GTK 3.22.24-3 (and in Crostini we have 3.22.11-1). I'll leave this bug open since we don't know for sure about a fix...but I don't plan to spend anymore time on it.
,
Jan 11
|
|||
►
Sign in to add a comment |
|||
Comment 1 by jkardatzke@chromium.org
, Oct 24