GDB doesn't stop at breakpoints (and when it finally does, it crashes the program)

I've tried to get help in the developer forum, but I think I should report this as a bug. The thread can be found at http://developer.qt.nokia.com/forums/viewthread/2625/. The following text is from the forum (with some editing).

For some reason I can't get gdb to work correctly with my QtCreator (v 2.0.94). The only error/warning I'm seeing is:

Debugging starts
&"warning: GDB: Failed to set controlling terminal: Invalid argument\n"

My environment looks like:

• 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.
I have been trying to work around this problem for several months, but have not found a solution.

Here 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"

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

I suddenly got it working, but I could find no special reason for it. I still think that this needs to be looked into, since the behavior is very erratic. Several other users are seeing what I have been seeing as well.

This is the logs for the working version: http://pastebin.com/yXQw4DJL
and the left split: http://pastebin.com/Rb5j5wS9

I'd say the behavior 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.