| 2018-03-12 08:25:27 |
Mark Jeronimus |
description |
I don't know if this is a side-effect of bug #10905 or a new phenomenon. It at least feels like the same behavior as "can't screenshot with menu open" that I see so often" only without the possibility of a lame workaround such as setting a delay time.
As a programmer, I'm trying to find a bug in my GUI, and for that I must place a breakpoint in the handler of a ComboBox. However, when I try to close the ComboBox, the debugger breaks my application with the ComboBox still open, and nothing responds anymore. This is a deadlock because Unity (or Xorg? or Compiz?) doesn't respond to mouse and keyboard input until I close it, but the code that closes it can't be resumed from the debugger without user interaction. The only way out I found is to "sudo killall Xorg" in another tty.
If a debug IDE and subprocess can cause this programmatically, then I can also imagine a third application can imitate this and this would be a security issue (partial denial of service). |
I don't know if this is a side-effect of bug #10905 or a new phenomenon. It at least feels like the same behavior as "can't screenshot with menu open" that I see so often" only without the possibility of a lame workaround such as setting a delay time.
As a programmer, I'm trying to find a bug in my GUI, and for that I must place a breakpoint in the handler of a ComboBox. However, when I try to close the ComboBox, the debugger breaks my application with the ComboBox still open, and nothing responds anymore. This is a deadlock because Unity 7.4.5 (or Xorg 1.18.4? or Compiz 0.9.12.3?) doesn't respond to mouse and keyboard input until I close it, but the code that closes it can't be resumed from the debugger without user interaction. The only way out I found is to "sudo killall Xorg" in another tty.
If a debug IDE and subprocess can cause this programmatically, then I can also imagine a third application can imitate this and this would be a security issue (partial denial of service). |
|
