Gdb stops at "setting breakpoints" in QtCreator when debugging

Azpegath

For some reason I can't get gdb to work correctly with my QtCreator (v 2.0.94). I've read several threads on it, but there seems to be surprisingly little to be found!

The only error/warning I'm seeing is:
@Debugging starts
&"warning: GDB: Failed to set controlling terminal: Invalid argument\n"@

This led me to posts like "this":http://www.qtforum.org/article/31905/debugging-qt-application-on-linux.html, which hasn't helped me either.

I'm using Gentoo Linux, with Qt 4.7.1 and QtCreator 2.0.94
I'm running gdb 7.2 (and not 7.0 which has been said to have some problem with QtCreator).
I'm building debug builds (I have also made sure that "-g" is in the Makefile)
gdb can be started from the terminal
The path to gdb is set (/usr/bin/gdb) and it IS started, it just freezes at "setting breakpoints", and after 20 seconds I get a warning message saying "The gdb process has not responded to a command within 20 seconds. This could mean it is stuck in an endless loop or taking longer than expected to perform the operation. You can choose between waiting longer or abort debugging."
I rebuilt the Debug Helper, which then got a green check-mark next to it.

My ldconfig.so.conf looks like
@# ld.so.conf autogenerated by env-update; make all changes to

contents of /etc/env.d directory

/usr/local/lib
include ld.so.conf.d/*.conf
/usr/lib32/opengl/xorg-x11/lib
/usr/lib64/opengl/xorg-x11/lib
/lib
/usr/lib
/lib64
/usr/lib64
/usr/local/lib64
/lib32
/usr/lib32
/usr/local/lib32
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/32
//usr/lib64/xulrunner-1.9.2
/usr/lib64/qca2
/usr/lib/qt4
/usr/lib64/qt4
/usr/lib32/qt4
/usr/lib64/sidplay/builders
/usr/lib/sidplay/builders
/opt/nvidia-cg-toolkit/lib
/usr/games/lib
/usr/games/lib64
/usr/games/lib32
/usr/lib32/libstdc++-v3/@

In the Run Settings for the Project I have "Debugger C++" checked, but not the "Run in terminal" check-box. I'm not using QML, so I don't have that enabled either.

If I need to supply more information, don't hesitate to ask! I have been trying to work around this problem for several months, but not being able to step through the code is just to painful...

Azpegath

We have the same issue in these different forums, but there does not seem to be any good answers.

Azpegath

This is some gdb info:

@=thread-group-added,id="i1"
~"GNU gdb (Gentoo 7.2 p1) 7.2\n"
~"Copyright (C) 2010 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type "show copying"\nand "show warranty" for details.\n"
~"This GDB was configured as "x86_64-pc-linux-gnu".\nFor bug reporting instructions, please see:\n"
~"http://bugs.gentoo.org/.\n"
(gdb)
-list-features
^done,features=["frozen-varobjs","pending-breakpoints","thread-info","python"]
(gdb)
q
&"q\n"@

Azpegath

Here's a Debugger Log (right split): http://pastebin.com/aiEKyaTV
And heres the Debugger commands (left split): http://pastebin.com/GwGcQuQj

Azpegath

Now it suddenly works, without me doing any changes! This is very strange...

This is the log for it: http://pastebin.com/yXQw4DJL
and the left split: http://pastebin.com/Rb5j5wS9

Azpegath

I'd say the behaviour is quite strange and erratic. If I stop at a breakpoint, the program crashes or gets locked up (for instance within a setScene or addText), but if I remove all breakpoints, it works.
It behaves like it's very timing dependent, and one breakpoint in the beginning brakes it. The annoying thing is of course that it shouldn't be timing dependent, it's just a simple application with only one thread.

Azpegath

Hello? Anyone? This is still an issue...

goetz

It's holiday time ... please wait for another couple of days.

jjpap

Hello,

I have the same problem...
I'm new on my fedora14 plateform and with Qt Creator 2.0.1 based on Qt 4.7.0 (64bits) and Gdb (7.2) I have this message in debug:

&"warning: GDB: Failed to set controlling terminal: Argument invalide\n"

and it not stop on my breaksPoints... :S

Any idea to solve this problem?

thx

jerome

tobias.hunger

The "controlling terminal" message can be ignored... nobody seems to know why gdb fails there (incl. the gdb developers):-(

From my experience most developers do not follow any forum. Bugreports and mailing lists are their way of communication. So please file a "bug report":http://bugreports.qt.nokia.com/ if you want to make sure the developers will be notified about the issue.

Azpegath

Thanks, I was looking for a place to do that! I did however think that the devs followed the official forum.

Azpegath

I've posted a bug about it, and I have received an answer as well. Seems like it's fixed in the 2.1 branch, so either you can try to apply the patch yourself (it's mentioned in the bug) or wait for the new release. Let's cross our fingers and hope it works!

http://bugreports.qt.nokia.com/browse/QTCREATORBUG-3534?focusedCommentId=138529#comment-138529

tobias.hunger

Glad you got your issue fixed:-)

Azpegath

I have tested the fix (just editing the dumper.py) and it seems to work a lot better now!

dimonomid

I moved to Linux in 2014, and I'm facing the same issue. (on Windows it worked nice)

Linux Mint 13 (Ubuntu 12.04 derivative), Qt Creator 3.0.1, Qt 5.2.1, gdb 7.4-2012.04. Behavior exactly the same: stuck on 'Setting breakpoints...', and after 40 seconds the message:

The gdb process has not responded to a command within 40 second(s). This could mean it is stuck in an endless loop or taking longer than expected to perform the operation. You can choose between waiting longer or aborting debugging.

I tried to install latest gdb 7.7, I have set my Qt project to use it, but nothing is changed.

How to solve it now?

Azpegath

It's strange that this old bug would resurface... Perhaps it's a regression in QtCreator. I haven't used it in a while, so I haven't seen if the bug has come back.

On another note, I would really recommend you to update to the latest version of Mint (if you're familiar with that and prefer it) since all dependencies are vastly updated on a modern version. Isn't it possible to do an upgrade to a newer version? Instead of a clean install I mean.

dimonomid

Thanks for the suggestion but I really want to stick to LTS release, so updating Mint is not an option for me.

Azpegath

LTS is overrated :) But I digress!

Perhaps you should either re-enable the bug to see if they can help you, or file a new bug and link to my old one.
Good luck!