This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #10 from Simon Marchi <simon.marchi at ericsson dot com> ---
(In reply to Mark Garvin from comment #9)
> Thanks for the extensive followup, Simon.  I have not dealt with GDB
> directly, so I'm not familiar with MI protocol.  I have to interact with the
> source program in order to load a target file, so I'll have to explore ways
> of issuing those commands afterward.

Ok, so you need to interact with the debugged program on the terminal at some
point?  In this case, the --tty option would be useful.  What you can do is
have GDB in one terminal, and the debugged program's input/output on another
terminal.

In the terminal in which you want to interact with your program, use the "tty"
command to get the name of the terminal device, then do a command like "tail -F
/dev/null" to avoid having the shell on that terminal read what you input (you
want it to go to the program you debug).  For example:

$ tty
/dev/pts/5
$ tail -F /dev/null

Then start gdb with the --tty switch:

$ gdb -i mi --tty /dev/pts/5

> From what you see in the log file, do you think there is any chance that
> this could be caused indirectly by the C++ code itself?  Granted that it
> should not be able to crash GDB or QtCreator, but my main concern was that
> there could be some reason for that crash beyond just some glitch within the
> debuggers.

The command that hangs is a custom Python script that runs inside GDB, but is
supplied by QtCreator.  Its purpose seems to be to dump the local variables in
a format that QtCreator expects.  A common problem is that when dealing with
uninitialized variables, you can end up with infinite loops (or just very long
ones).  For example, an uninitialized std::vector can happen to report a
ridiculously long size, making the debugger appear stuck while it tries to read
billions of elements.  That's only a guess, the only way to find out is to
close in step by step towards the root of the problem.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]