Debugging QT2.3.2 programs with gdb
Recipient: [EMAIL PROTECTED]>
Reason: unknown user - prep.ai.mit.edu
is deprecated, try gnu.org
Original Message
Subject:
Debugging QT2.3.2 programs with gdb
Date:
Tue, 29 Oct 2002 15:08:58 -0500
From:
Allen King [EMAIL PROTECTED]>
To:
[EMAIL PROTECTED], [EMAIL PROTECTED]
I am ATTEMPTING to debug a large QT program and am having a bear of
a time using gdb. This incompatibility often takes over 2/3'rds of
my debug time.
The issue is viewing QString's. On a good day, I can get some information
out of str->latin1(), except most of my strings are not purely latin1,
and on those latin1 is useless.
If I do "p str", sometimes I get the not very helpful message:
$3 = (QString ) @0x41c9321c: {
static null = Cannot access memory at address 0x0
Other times (one in 10) the whole of gdb crashes. E.g. gdb runs
are limited to doing about 10 things.
When I attempt to use my own "p print_QString(str)" from the debugger,
gdb spends about 2 minutes examining my symbol table and then either says:
"couldn't resolve", 1 in 3 works properly, or crashes gdb.
Do you have any workarounds? I've looked under your debugging
and FAQ sections and seen nothing. It is starting to make me want
to stear clear of QT in the future. And yes, I need to debug with
a debugger. I'd be happy to send you stuff to replicate it if I know you
are going to look at it.
I am using:
RedHat 8.0 (it's the same on 7.2 and 7.3, I've been there)
GNU gdb Red Hat Linux (5.2.1-4)
running gdb from xterm, emacs, or ddd gives equal (poor) results.
gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
also the same with gcc 3.0.2
a typical make output is:
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/lib/qt-2.3.2/include
-I/usr/X11R6/include -D_REENTRANT -Wall -g -DDEBUG -DQT_THREAD_SUPPORT=1
-c -o kbd2eq.o kbd2eq.cpp
I have optimizations off for debugging
I have played around with the -ggdb switch, and it seems better not
there
I
[Fwd: Gdb breakpoint bug with gcc3 on RedHat7.2]
An update on the bug:
a) it also exists in gcc-3.0.3 (I compiled it yesterday
from ftp.gnu.org).
b) a breakpoint in a non-constructor method (e.g. imagine
foo::goo() below) works.
Any thoughts?
Original Message
Subject:
Gdb breakpoint bug with gcc3 on RedHat7.2
Date:
Tue, 22 Jan 2002 14:59:57 -0500
From:
Allen King [EMAIL PROTECTED]>
To:
[EMAIL PROTECTED]
CC:
Brian King [EMAIL PROTECTED]>
/*:
There seems to be a bug in gdb which causes it to not stop at certain
breakpoints. It occurs with C++ sources compiled with gcc3-3.02,
but not when
gcc2-2.96 is used. All gdb versions I tried (ver 5.0rh-15 and
5.1.0.1) had
the same problem.
I'm suspecting there may be newer versions around which have had this
(rather
basic) bug fixed, or perhaps I'm doing something wrong (..naaw).
If you can, I could use workaround/upgrade suggestions quick, as I
live in gdb
and have found progress come to a grinding halt.
The program I first encountered this in was rather large (64K lines),
but I
isolated the behavior down to the following 16-line program:
//
(line 0)
#include stdio.h>
class foo {
public:
foo ();
};
int main (int argc, char **argv) {
foo *myObject = new foo ();
// A (line 9)
return myObject!=0; // reference it
}
foo::foo () {
printf("Why didn't the gdb breakpoint stop here?\n");
//B (line 14)
}
/* vv
Info (per www.gnu.org/manual/gdb-4.17/html_chapter/gdb_18.html) is:
gcc:
Both gcc3-3.0.1-3.i386.rpm (and friends) (which I did most work on)
and
gcc3-3.0.2-1hn.i586.rpm (and friends) (just installed) seem to have
the same
problem. gcc2-2.96 works fine -- stops at both breakpoints.
Gdb:
5.0rh-15 (from 7.2 CD) and 5.1.0.1 (made with gcc3) have the same problem.
OS:
RedHat.7.2, vmlinuz-2.4.7.
CPU:
AMD-K6(tm) 3D processor, 400MHz
Build and Recreate Problem:
Gdb fails to stop at the breakpoint on line 14 of the above program.
However
it is clear that line 14, a printf, does get executed -- My console
log:
[me@gibson src]$ g++ --version
3.0.2
[me@gibson src]$ g++ -g main.cpp -o main
[me@gibson src]$ gdb ./main
GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) b 9
Breakpoint 1 at 0x804874d: file main.cpp, line 9.
(gdb) b 14
Breakpoint 2 at 0x80487de: file main.cpp, line 14.
(gdb) r
Starting program: /home/me/main
Breakpoint 1, main (argc=1, argv=0xb1d4) at main.cpp:9
9 foo *myObject
= new foo ();
// A
(gdb) inf b
Num Type
Disp Enb Address What
1 breakpoint keep y
0x0804874d in main at main.cpp:9
breakpoint already hit 1
time
2 breakpoint keep y
0x080487de in foo::foo(int*, char const*)
at main.cpp:14
(gdb) l 14
14 printf("Why didn't the gdb breakpoint stop here?\n");
//B
(gdb) c
Continuing.
Why didn't the gdb breakpoint stop here?
Program exited with code 01.
Aside
In upgrading RedHat7.2 to gcc3, I hit a knarrly problem, which I solved.
However it involved much more hackery than I would have expected, so
I'm
just bringing it up as a double check: I had loaded/installed rpm's
as follows:
gcc3-3.0.1-3.i386.rpm
gcc3-c++-3.0.1-3.i386.rpm
libgcc-3.0.1-3.i386.rpm
libstdc++3-3.0.1-3.i386.rpm
libstdc++3-devel-3.0.1-3.i386.rpm
and compiles gave the error: "cannot find deque.h". File libstdc++-v3/README
had the cryptic comment: "(A configure script may link files from another
directory into one of these.)
The hack I did was to add about 200 symbolic links:
in /usr/include/bits, added symlinks to all files
(not directories)
in the following directories:
/usr/include/g++-v3
/usr/include/g++-v3/bits
/usr/include/g++-v3/i386-redhat-linux/bits
and in /usr/include, added symlinks to all files
in directory:
/usr/include/g++-v3/backward
How I determined this was by a painstaking series of compillations of
a C++
program which referenced deque.h, isolating the missing include files
and
linking where the above rpms' placed them.
Compillations after this were errorless.
--
Allen
781-248-6897 cell
781-449-3359 home
Gdb breakpoint bug with gcc3 on RedHat7.2
/*:
There seems to be a bug in gdb which causes it to not stop at certain
breakpoints. It occurs with C++ sources compiled with gcc3-3.02,
but not when
gcc2-2.96 is used. All gdb versions I tried (ver 5.0rh-15 and
5.1.0.1) had
the same problem.
I'm suspecting there may be newer versions around which have had this
(rather
basic) bug fixed, or perhaps I'm doing something wrong (..naaw).
If you can, I could use workaround/upgrade suggestions quick, as I
live in gdb
and have found progress come to a grinding halt.
The program I first encountered this in was rather large (64K lines),
but I
isolated the behavior down to the following 16-line program:
//
(line 0)
#include stdio.h>
class foo {
public:
foo (int* parent = 0, const char *name = 0);
};
int main (int argc, char **argv) {
foo *myObject = new foo (0, "interface");
// A (line 9)
return myObject!=0; // reference it
}
foo::foo (int *parent, const char *name) {
printf("Why didn't the gdb breakpoint stop here?\n");
//B (line 14)
}
/* vv
Info (per www.gnu.org/manual/gdb-4.17/html_chapter/gdb_18.html) is:
gcc:
Both gcc3-3.0.1-3.i386.rpm (and friends) (which I did most work on)
and
gcc3-3.0.2-1hn.i586.rpm (and friends) (just installed) seem to have
the same
problem. gcc2-2.96 works fine -- stops at both breakpoints.
Gdb:
5.0rh-15 (from 7.2 CD) and 5.1.0.1 (made with gcc3) have the same problem.
OS:
RedHat.7.2, vmlinuz-2.4.7.
CPU:
AMD-K6(tm) 3D processor, 400MHz
Build and Recreate Problem:
Gdb fails to stop at the breakpoint on line 14 of the above program.
However
it is clear that line 14, a printf, does get executed -- My console
log:
[me@gibson src]$ g++ --version
3.0.2
[me@gibson src]$ g++ -g main.cpp -o main
[me@gibson src]$ gdb ./main
GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) b 9
Breakpoint 1 at 0x804874d: file main.cpp, line 9.
(gdb) b 14
Breakpoint 2 at 0x80487de: file main.cpp, line 14.
(gdb) r
Starting program: /home/me/main
Breakpoint 1, main (argc=1, argv=0xb1d4) at main.cpp:9
9 foo *myObject
= new foo (0, "interface");
// A
(gdb) inf b
Num Type
Disp Enb Address What
1 breakpoint keep y
0x0804874d in main at main.cpp:9
breakpoint already hit 1
time
2 breakpoint keep y
0x080487de in foo::foo(int*, char const*)
at main.cpp:14
(gdb) l 14
14 printf("Why didn't the gdb breakpoint stop here?\n");
//B
(gdb) c
Continuing.
Why didn't the gdb breakpoint stop here?
Program exited with code 01.
Aside
In upgrading RedHat7.2 to gcc3, I hit a knarrly problem, which I solved.
However it involved much more hackery than I would have expected, so
I'm
just bringing it up as a double check: I had loaded/installed rpm's
as follows:
gcc3-3.0.1-3.i386.rpm
gcc3-c++-3.0.1-3.i386.rpm
libgcc-3.0.1-3.i386.rpm
libstdc++3-3.0.1-3.i386.rpm
libstdc++3-devel-3.0.1-3.i386.rpm
and compiles gave the error: "cannot find deque.h". File libstdc++-v3/README
had the cryptic comment: "(A configure script may link files from another
directory into one of these.)
The hack I did was to add about 200 symbolic links:
in /usr/include/bits, added symlinks to all files
(not directories)
in the following directories:
/usr/include/g++-v3
/usr/include/g++-v3/bits
/usr/include/g++-v3/i386-redhat-linux/bits
and in /usr/include, added symlinks to all files
in directory:
/usr/include/g++-v3/backward
How I determined this was by a painstaking series of compillations of
a C++
program which referenced deque.h, isolating the missing include files
and
linking where the above rpms' placed them.
Compillations after this were errorless.
--
Allen
781-248-6897 cell
781-449-3359 home
