"Program" is not responding when debugging in gdb

Bug #1832426 reported by Eric Shaw
This bug affects 8 people
Affects Status Importance Assigned to Milestone
gnome-shell (Ubuntu)

Bug Description

I believe this is a regression for ​​bug 1740869:
<something> is not responding window is constantly showing when debugging a program

I'm debugging my c++ sdl2 program in gdb and when I hit a breakpoint this window shows up and I can't get it to stop asking me to close the program.

1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu
Description: Ubuntu 19.04
Release: 19.04

2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center
  Installed: 3.32.1-1ubuntu1~19.04.1
  Candidate: 3.32.1-1ubuntu1~19.04.1
  Version table:
 *** 3.32.1-1ubuntu1~19.04.1 500
        500 http://us.archive.ubuntu.com/ubuntu disco-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     3.32.0+git20190410-1ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages

3) What you expected to happen
When I hit a breakpoint in gdb, the program should stop.

4) What happened instead
The program stops and ubuntu asks me if i want to kill the program.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: gnome-shell 3.32.1-1ubuntu1~19.04.1
ProcVersionSignature: Ubuntu 5.0.0-16.17-generic 5.0.8
Uname: Linux 5.0.0-16-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jun 11 22:03:44 2019
DisplayManager: gdm3
InstallationDate: Installed on 2019-06-08 (4 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
 PATH=(custom, no user)
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Eric Shaw (ericshaw-linux) wrote :
description: updated
Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote :

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?

Revision history for this message
Eric Shaw (ericshaw-linux) wrote :

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.


Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Revision history for this message
Irbys (white-irbys) wrote :

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

Repeatedly warning "MyApp is not responding" under debugging

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Changed in gnome-shell (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Evgeniy Check (check300373) wrote :

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.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I think this is fixable per comment #4.

Revision history for this message
Evgeniy Check (check300373) wrote :

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".

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Revision history for this message
Evgeniy Check (check300373) wrote :

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?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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.

Revision history for this message
Timo Suoranta (tksuoran) wrote :

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.

Revision history for this message
Joan (jmigual) wrote :

I am also affected in Ubuntu 19.10

tags: added: eoan
tags: removed: disco
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Is this still an issue in Ubuntu 20.04?

Changed in gnome-shell (Ubuntu):
status: Confirmed → Incomplete
tags: removed: eoan
Revision history for this message
tuket (tuketelamodelmon) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-shell (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Ömer GÖK (omergok) wrote :

I'm experiencing this issue in ubuntu 22.10.

Changed in gnome-shell (Ubuntu):
status: Expired → Confirmed
tags: added: kinetic
Revision history for this message
Chaim Eliyah (chaimeliyah) wrote (last edit ):

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.

Revision history for this message
ekso (ekso) wrote :

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.

Revision history for this message
Hylke Hellinga (hylke-hellinga) wrote :

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:

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?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.