"Program" is not responding when debugging in gdb

Mh, if the warning is just showing once and when you unfocus such dialog you don't get any problem, I don't think this is an issue.

Maybe the fix would be to delay the presentation of such dialog until the hanging window is focused?

Hi Marco,

No, the warning/dialog shows repeatedly.

I think if I'm debugging a program, ubuntu and gnome-shell should never tell me the window is not responding. I might focus the window to use it, or to set it above all others so I can watch it.

Thanks

I think gnome-shell could do better at ignoring programs being debugged. It appears you can detect this by looking at the process state like in /proc/PID/status. It will show:

State: t (tracing stop)

Or easier to parse: Look at /proc/PID/stat and the third field will be a lowercase 't'.

This means the process is being debugged and gnome-shell should not be raising warnings about it.

The same problem.
Ubuntu 18.04
QT Creator (gdb 8.2)
gnome-shell 3.28.4

Repeatedly warning "MyApp is not responding" under debugging

Bug #1740869 was another issue and about the fact that the dialog would lead input to stop working, the bug here is about the fact that those dialogs are an annoyance and should be avoided for debuggers

Hello to all. Ubuntu 18.04.2 LTS. Eclipse based application. Upgrading gnome-shell up to 3.28.4 was useless. The annoying popup message during debugging application is still appearing.

I think this is fixable per comment #4.

Hello, Daniel. Please tell me where (how) I can see this state. I've looking for this in gnome-system-monitor, the state of debugging application is "Waiting". I've looking foe this in "top" - column "S" is "S" value, not "t".

It is in the file /proc/PID/status or /proc/PID/stat for each PID.

OK, Daniel, thank You, now it clear. I've found this file.
State: S (sleeping)
So the appearing of popup message is correct, because not correct state of process. What process must set this state for debugging application? Same debugger?

No, the kernel sets it when a program being debugged is stopped in the debugger. If you see "S (sleeping)" then that implies you haven't yet stopped the program being debugged.

I am also affected by this bug, currently using Ubuntu 19.10, and previously I had 19.04, both have the issue. It is really annoying because the window system becomes temporarily completely unresponsive and I am not even able to click on anything.

I am also affected in Ubuntu 19.10

Is this still an issue in Ubuntu 20.04?

I would also like to know if this is fixed in 20.04. I would want to upgrade if so.
Thanks.

[Expired for gnome-shell (Ubuntu) because there has been no activity for 60 days.]

I'm experiencing this issue in ubuntu 22.10.

Forgive me if I missed something in reading but is there a link to a bug on the Gnome side? This seems absolutely _constant_ in 22.04, and interrupts many games and programs. It seems like a really bad idea given that many programmers are relying on async tasks/callbacks/etc. these days. Impetus should be on the user to force quit a program that isn't responding; don't need the ...errr 'helpful' box. (: In any case I know it isn't about this team specifically, but would like to follow up with Gnome.

Also there are a lot of links to this bug around, e.g., askubuntu; but the problems are not all related to programs hanging when debugging, it's just that people keep closing other references as duplicates. To be clear, it's not just affecting developers. This happens to me in Thunderbird, Firefox, Chrome, Steam... the list goes on.

I also have this problem when hitting a breakpoint in Unreal 5.1 from JetBrains Rider 2022.3.1 while in vanilla Ubuntu 22.04. When the window shows it actually makes the mouse pointer disappear and I have to rely on the keyboard to "Force Quit" to get the pointer back.

The "Disable Force Quit or Wait" gnome-shell extension does work and solves the problem: https://extensions.gnome.org/extension/2257/disable-force-quit-or-wait-button/

With that being said, I have to agree with Daniel van Vugt on comment #4, the status on Unreal PID does change from "S" to "t" when the breakpoint is hit.

I'm also affected by this same bug mentioned by ekso in unreal with rider using other distributions that are based off of ubuntu, like for example pop-os (with gnome-shell installed, not the cosmic DE).

I've created a forum post on the epicgames community forum about this issue as well here:
https://forums.unrealengine.com/t/debugging-in-rider-on-ubuntu-linux-gnome-causes-editor-or-game-to-freeze-on-breakpoints-causing-no-mouse-to-appear/835140/2

As I said in the forum post: Perhaps there is a way to make gnome aware that an application is being debugged so that it doesn't force a dialog window with wait for a response or force quit "crash". Or perhaps make it so that the cursor still appears when such a dialog appears, allowing for other applications to become interact-able with the mouse?