2010-11-18 09:26:20     Debugging Qt application / POSIX threads

Document created by Aaronwu Employee on Aug 23, 2013
Version 1Show Document
  • View in full screen mode

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

Attachments

Outcomes