2010-11-18 09:26:20 Debugging Qt application / POSIX threads
Andreas Schallenberg (GERMANY)
Message: 95946
Hello,
while debugging an application built with Qt 4.6.3 I found that breakpoints
in QThreads are ignored. I stripped the application down to a smaller example
which is attached to this mail.
The application structure is simple:
In main() a QObject ("InitObject" class) is created that itself spawns a
thread ("SpawnedThread" class). In "common.h" is a macro that is used
to print the current position to stdout. A normal execution looks like this:
"int main(int, char**):9 " A
"int main(int, char**):13 " B
"void InitObject::startupSlot():17 " A
"void InitObject::startupSlot():19 " B
"virtual void SpawnedThread::run():13 " A
"virtual void SpawnedThread::run():15 " B
"void InitObject::startupSlot():21 " C
"void InitObject::startupSlot():23 " D
"int main(int, char**):15 " C
This works both on my PC and the embedded board. However, when I
insert breakpoints, the execution is different on the target board.
I inserted three breakpoints, each on the line printing "A".
The first two breakpoints are reached, but when "continue"ing
at the second breakpoint, I get this:
gdbserver :1234 ./testapp.us
Process ./testapp.us created; pid = 397
Listening on port 1234
Remote debugging from host 10.100.100.12
"int main(int, char**):9 " A
"int main(int, char**):13 " B
"void InitObject::startupSlot():17 " A
"void InitObject::startupSlot():19 " B
Child exited with retcode = 0
Child exited with status 0
GDBserver exiting
This happens on the target board only. The environment I used is
uClinux 2009R1.1-RC4, toolchain 2009R1.1. The board is the
DNP/5370 with Blackfin 537-0.3.
AFAIK Qt uses pthreads for its concurrency support.
I compiled with these flags:
-pipe -O0 -Wall -D__uClinux__ -DEMBED -fno-builtin -g3 -pthread -fPIC -mstack-check-l1 -mcpu=bf537-0.3 -fstack-check -Wextra -Wno-unused-parameter -rdynamic
Link flags:
-Wl,-warn-common -Wl,-warn-common -pthread -fPIC
I used the bfin-linux-uclibc-insight debugger.
Are such problems with POSIX threads on the architecture known or is it supposed to work?
Are later releases of uClinux supposed to behave better? Or am I missing a fundamental problem?
Andreas
testapp.tar
TranslateQuoteReplyEditDelete
2010-11-19 04:42:41 Re: Debugging Qt application / POSIX threads
Andreas Schallenberg (GERMANY)
Message: 95990
The example can be reduced further:
#include <stdio.h>
#include <pthread.h>
void* f1(int *x)
{
int i;
i = *x;
printf("%s: A %d\n", __func__, i);
pthread_exit(0);
}
int main(int argc, char ** argv)
{
pthread_t f1_thread;
int i;
i = 1;
printf("%s: A %d\n", __func__, i);
pthread_create(&f1_thread,NULL,(void*(*)(void*))f1,&i);
pthread_join(f1_thread,NULL);
printf("%s: B %d\n", __func__, i);
}
(It is a stripped down version of
cs.gmu.edu/~white/CS571/Examples/Pthread/create.c )
Running it gives:
/media/mmc # ./ct.us
main: A 1
f1: A 1
main: B 1
And remote debugging it (placing breakpoints at the lines printing "A"):
/media/mmc # gdbserver :1234 ./ct.us
Process ./ct.us created; pid = 391
Listening on port 1234
Remote debugging from host 10.100.100.12
main: A 1
Child exited with retcode = 0
Child exited with status 0
GDBserver exiting
So the issue cannot be caused by Qt. Can somebody confirm this behavior?
TranslateQuoteReplyEditDelete
2010-11-19 08:17:23 Re: Debugging Qt application / POSIX threads
Andreas Schallenberg (GERMANY)
Message: 96009
Just a quick update for the record:
Found this website:
www.armadeus.com/wiki/index.php?title=GDB#Troubleshots
Quote:
"libthread_db.so (db == debug) is a library that is needed when you want to debug programs using pthread."
A search on the target showed:
/media/mmc # find / | grep thread
/lib/libthread_db.so.1
/media/mmc/lib/libpthread.so.0
/media/mmc/lib/libthread_db.so.1
/proc/sys/kernel/threads-max
/proc/sys/vm/nr_pdflush_threads
So the library is there. While debugging the app (sitting at the breakpoint):
/proc/399 # cat maps
00609000-0060a000 r-xp 00000000 b3:01 27 /media/mmc/ct.us
0060a000-0060b000 rw-p 00000000 b3:01 27 /media/mmc/ct.us
0060b000-0060c000 rw-p 00007000 1f:03 12 /lib/ld-uClibc.so.0
0060c000-0060e000 rw-p 00000000 00:00 0
00610000-00618000 r-xp 00000000 1f:03 12 /lib/ld-uClibc.so.0
0061a000-0061b000 rw-p 00000000 00:00 0
0061b000-0061c000 rw-p 00000000 00:00 0
0061c000-00620000 rw-p 00000000 00:00 0
00620000-00640000 rwxp 00000000 00:00 0
00640000-0064c000 r-xp 00000000 1f:03 13 /lib/libgcc_s.so.1
00650000-0065a000 r-xp 00000000 b3:01 40 /media/mmc/lib/libpthread.so.0
00660000-00662000 rw-p 00000000 00:00 0
00668000-00670000 rw-p 00000000 00:00 0
00670000-00680000 r-xp 00000000 b3:01 39 /media/mmc/lib/libm.so.0
00680000-006a5000 rw-p 00000000 00:00 0
006c0000-006fe000 r-xp 00000000 1f:03 19 /lib/libc.so.0
00700000-007aa000 r-xp 00000000 b3:01 38 /media/mmc/lib/libstdc++.so.6
00800000-00802000 rw-p 00000000 00:00 0
00802000-00803000 rw-p 00000000 00:00 0
00803000-00804000 rw-p 00000000 00:00 0
011a8000-011a9000 rw-p 00000000 00:00 0
01221000-01222000 rw-p 00000000 00:00 0
015c1000-015c2000 rw-p 00000000 00:00 0
So it loads libpthread but not libthread_db. Maybe this is a part of the problem.
Second observation:
> file romfs/lib/libthread_db.so.1
romfs/lib/libthread_db.so.1: ELF 32-bit LSB shared object, Analog Devices Blackfin, version 1 (SYSV), dynamically linked (uses shared libs), stripped
But in later releases the lib should be no longer stripped:
[9733] trunk/vendors/AnalogDevices/vendor.mak: [#5786] dont strip libthread_db.so as it is needed for debugging only
2010-07-25 13:58:56 GMT
Revision 9733 Author vapier Date 2010-07-25 09:58:55 -0400 (Sun, 25 Jul 2010)
I'll see it I can get it to load libthread_db. Maybe that is a part of the solution.
TranslateQuoteReplyEditDelete
2010-11-19 10:33:24 Re: Debugging Qt application / POSIX threads
Andreas Schallenberg (GERMANY)
Message: 96014
That was a dead-end. "ldd" says the working PC version also uses libpthread.
TranslateQuoteReplyEditDelete
2010-11-23 10:44:54 Re: Debugging Qt application / POSIX threads (solved)
Andreas Schallenberg (GERMANY)
Message: 96139
Just in case anyone has the same issue:
Switched to uClinux 2010R1-RC3 and it behaves better.
> gdbserver :1234 ./ct.us
Process ./ct.us created; pid = 390
Listening on port 1234
Remote debugging from host 10.100.100.12
main: A 1
Child terminated with signal = 5
Child terminated with signal = 0x5 (SIGTRAP)
GDBserver exiting
SIGTRAP is documented in the GDB manual, now the child
process receives the signal but has no debugger attached to it.
(-> gdb "follow-fork-mode")