QtCreator/GDB stall when breakpoint set
-
Extremely odd bug: Project uses Qt and OpenCV under Linux. When a breakpoint is set immediately after one of the OpenCV statements (call to findContours, for anyone curious), QtCreator stalls. After 40 seconds or so, there is a popup saying that GDB is not responding, with a prompt asking to continue or not. Pressing 'continue' just stalls indefinitely--I've let it go for over 30 minutes with no response.
During the stall, QtCreator's 'continue' and stop buttons are grayed out. There is no way to interact with QtCreator. The only escape is to stop the process by pressing 'no' when the initial GDB message comes up, or just aborting QtCreator.
The odd thing: If no breakpoint is set, the program just continues and functions as expected. There seems to be something about setting the breakpoint after the call to OpenCV function, but it's difficult to get any additional clues. The function call itself is nothing unusual. Fairly generic textbook code sequence.
I've been working with QtCreator as a dev environment for about 6 months, and this is the first that I've seen anything like this. It's difficult to say whether this is a QtCreator bug or a glitch with GDB, or a combination.
The other odd aspect is that QtCreator provides no way to break out of the ozone loop, aside from just waiting for the GDB timeout message.
Has anyone seen anything like this? I'm hoping it's documented behavior that can be addressed.
-
QtCreator version is 4.5.1, with Qt version 5.10.1.
The version is from around Feb 2018. I haven't wanted to update anything for fear of breaking running code.
Development in C++ (GCC), under Linux Mint 18.1.
-
OK, here is what I found. Hopefully will help those with similar problems:
I updated Qt and QtCreator to the latest version:
No helpI updated GDB to v8.2, which was a pain. The normal Linux command line
install reported that 7.11 was already the latest. Incorrect. So I had to build
v8 from scratch which took quite a while.
But still no help.Then I changed the QtCreator C++ compiler settings from GCC to Clang++.
That seems to have done the trick.Still no idea why this occurred, but perhaps it was yet another GCC bug.
We'll see if this stays fixed. This was a rather unsettling bug, since it was
impossible to tell if it was a problem with source code, or was coming from
QtCreator, or GDB, or the compiler. It seemed to shift around with changes
in source, and where the breakpoint was placed. -
Spoke too soon (damn!) The bug is still there, but just shifted. By that, I mean that breakpoints that are set in the places that originally caused the bug to surface now work correctly. But I just placed a breakpoint elsewhere, and the same behavior resurfaced: GDB stall, with Qt prompt to keep going or abort after 40 second timeout.
At this point, I have to think that this is a GDB bug. It could still be something else, but when the debugger itself goes away, never to return, it points to the debugger as the culprit.
It also seems that Qt should have a responsive button to break out of conditions like this, and perhaps some feedback about what was going on at the point of the break.
-
Hi @StringTheory said in QtCreator/GDB stall when breakpoint set:
I can't remember having seen such a strange behavior. Recently I had debugged a profile build by accident - that was already strange enough. Have you checked that's not the case for you?
At this point, I have to think that this is a GDB bug. It could still be something else, but when the debugger itself goes away, never to return, it points to the debugger as the culprit.
Well, you could try to use GDB from the command line, but who want's that...
It also seems that Qt should have a responsive button to break out of conditions like this, and perhaps some feedback about what was going on at the point of the break.
Have you already had a look in the debugger log (Windows > Views > Debugger Log)?
Regarding the button: I'm unsure if it's needed often (I guess you can stop debugging with the same consequence), but maybe the feedback could be really better.
Regards and good luck!
-
@aha_1980 : Actually, that is very helpful; the only real clue about this so far. The relevant statements at the point where GDB stalls:
d252: python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["return","inspect","local","watch"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","token":252,"typeformats":{},"watchers":[]})
d253: -exec-continue
dTIMED OUT WAITING FOR GDB REPLY. COMMANDS STILL IN PROGRESS: "-exec-continue", "python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["return","inspect","local","watch"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","token":252,"typeformats":{},"watchers":[]})"
I'm not sure why "python theDumper" appears in a debug session for C++ code, but perhaps it's used in GDB somehow.
-
@StringTheory said in QtCreator/GDB stall when breakpoint set:
I'm not sure why "python theDumper" appears in a debug session for C++ code, but perhaps it's used in GDB somehow.
The python dumpers are used to show the contents of complex variables like
QStringListin a human readable format.The questions is, if the python dumpers add some extra problems for you. That's why I suggested to try
gdbfrom command line and break at the same position to see if its working from there. -
@aha_1980 : Oh, so the Python dumper message is from Qt. The log file must be a combination of Qt and GDB messages then. That sounds even more difficult to sort out.
I suppose I've got to get up to speed on GDB. I've never used it stand-alone, so I'll have to figure out what's required to load symbols and such.
That's a helpful observation. Thanks.
-
@aha_1980 : I just noticed something else: In the log file, there are lines saying "GDB 71101", presumably because it is using v7.11.1 (?!). But I have installed GDB v8.2 in both usr/bin and usr/local/bin. And I've set those locations in QtCreator's options pages for kits and for debuggers. There should be no way for QtCreator to find an older GDB version.
The GDB version in both usr/ folders above is 8.2, confirmed by running via terminal. And I did not find any older stray 7.11.1 versions that QtCreator could be picking up.
Another oddity. Is there any other options page where the GDB location needs to be set?
