This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug c++/23639] QtCreator stall and timeout after 40 seconds due to GDB
- From: "simon.marchi at ericsson dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Sat, 15 Sep 2018 10:05:54 +0000
- Subject: [Bug c++/23639] QtCreator stall and timeout after 40 seconds due to GDB
- Auto-submitted: auto-generated
- References: <bug-23639-4717@http.sourceware.org/bugzilla/>
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.