[Bug c++/23639] QtCreator stall and timeout after 40 seconds due to GDB

["simon.marchi at ericsson dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=23639

--- Comment #12 from Simon Marchi <simon.marchi at ericsson dot com> ---
(In reply to Mark Garvin from comment #11)
> Hi again, Simon.
> 
> It looks like you are very familiar with QtCreator's interface to GDB! 
> That's a pleasant surprise.  I had expected this to fall through the cracks
> after seeing very little feedback on Qt forums.
> 
> It does appear that I'll need to get familiar with GDB and its commands, so
> I've been looking into it.  Given the touchy nature of this bug, I'm not
> sure if it will be easily reproduced when running directly in GDB.  Tiny,
> seemingly insignificant, changes to C++ source can make the difference
> between whether GDB stalls or not.

Well, if you can manage to reproduce the bug reliably in QtCreator, you should
be able to reproduce it reliably out of QtCreator.  As long as it's not a
time-sensitive issue (race condition), giving the exact same inputs (same
binary, same commands) to GDB should yield the same results.

If you need help to try to reproduce the bug outside of QtCreator, feel free to
hop on the #gdb IRC channel to get some more interactive help.

> The latest oddity:  I went back to a previous version that did not exhibit
> the 'stall after breakpoint' behavior.  I incrementally updated it to get
> closer to my newest code, testing for the stall bug at every step.  I
> arrived at a version of the source that stalls if a single -declaration- for
> an OpenCV Mat object is inserted.  In other words:
> 
>   Mat nullMat;
> 
> will stall GDB, even if nullMat is never used or referenced.  That is about
> as generic an OpenCV statement as can be written. No way should that be able
> to trigger anything. Commenting that line suppresses the GDB stall.  In the
> years that I've been coding, don't recall ever seeing anything like this.
> 
> Moving the "Mat nullMat;" declaration to other locations nearby will still
> stall GDB.

In all these cases, it's a local variable in the function where you are
stopped?

> Again, the breakpoint does not need to be set on any particular statement,
> as long as it is within a range of code in the function.  Execution stops
> correctly on the breakpoint, but continuing execution afterward stalls GDB
> indefinitely.

That seems to confirm my theory QtCreator's script that reads and prints the
local variables is stuck in an endless loop.

> I confirmed that GDB/QtCreator can be left running for 8 hours or longer,
> and it never returns.
> 
> If a breakpoint is not set, the code does not crash or behave strangely in
> any way.  It appears to run perfectly.  It is the temporary stop at the
> breakpoint that triggers this.

Yes, because it's not your program that is stuck, it's the debugger.

> Also odd: This is a program for processing graphic images (preprocessing for
> neural nets).  Loading certain images will suppress the stall bug.  No idea
> why, as they are often very similar to other images that, when loaded,
> result in the stall.  Again, -none- of the images causes any odd behavior if
> the simple OpenCV Mat declaration is commented out.
> 
> I thought it was worth reiterating some of this, as I've had a chance to
> repeat the tests quite a few times.  Perhaps the additional clues above will
> help to clarify the problem.
> 
> I realize it is a subjective question, but does any of this sound like it
> could be induced by the code itself?  That is my main concern.  To me, it
> looks more and more like some corner case within the QtCreator/GDB debugger
> itself, but you'd be able to make a more informed guess.  Have you seen
> anything like this before?

It's most certainly not a problem with your code.

I have seen similar problems with the libstdc++ pretty printers (the things
that print std::vector nicely, for example).  When stopping before the
std::vector is initialized, the pretty printer can behave very badly, including
entering a seemingly endless loop.

So in your case, do you ever encounter the bug if the breakpoint is placed
after the declaration of all Mat objects?

> 
> MG
> NYC
> 
> PS: Interaction with the program is via Qt GUI, so it's not as simple as
> enabling console commands.  I'll have to hard-code commands to load files
> and such, and hope that the bug is still triggered.

-- 
You are receiving this mail because:
You are on the CC list for the bug.