Program terminated by SIGTRAP in gdb

Program terminated by SIGTRAP in gdb

[Albert Fu]

Hi,

I am new to debug a multi-thread program in gdb on my target.

The program is terminated when it calls sem_wait().
I browsed the gdb mailing list and didn't find an answer to my problem.

######################
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0fe2ba28 in sigsuspend () from /lib/libc.so.6
(gdb) bt
#0  0x0fe2ba28 in sigsuspend () from /lib/libc.so.6
#1  0x0fd91094 in pthread_getconcurrency () from /lib/libpthread.so.0
#2  0x0fd920f0 in sem_wait () from /lib/libpthread.so.0
#3  0x10016428 in main (argc=2, argv=0x7ffffdf4) at main.c:7361
(gdb) info threads
(gdb) info sharedlibrary
From        To          Syms Read   Shared Object Library
0x0fe15aa0  0x0ff1dd20  Yes         /lib/libc.so.6
0x0fd8d0c0  0x0fd95d2c  Yes         /lib/libpthread.so.0
0x30001f60  0x30013980  Yes         /lib/ld.so.1
0x0fd6006c  0x0fd67a6c  No          /lib/libnss_files.so.2
(gdb)
######################

Could you tell me why the program is supspended? Is the problem
in the C library?

I would really appreciate it if anyone could give me some advices.

Thanks.

Best regards,

Albert

Re: Program terminated by SIGTRAP in gdb

[teawater]

I think is because your libpthread is stripped.  Maybe you can check
it and make sure it's not stripped.

On Thu, Jan 15, 2009 at 08:37, Albert Fu <quarkverse@gmail.com> wrote:
> Hi,
>
> I am new to debug a multi-thread program in gdb on my target.
>
> The program is terminated when it calls sem_wait().
> I browsed the gdb mailing list and didn't find an answer to my problem.
>
> ######################
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x0fe2ba28 in sigsuspend () from /lib/libc.so.6
> (gdb) bt
> #0  0x0fe2ba28 in sigsuspend () from /lib/libc.so.6
> #1  0x0fd91094 in pthread_getconcurrency () from /lib/libpthread.so.0
> #2  0x0fd920f0 in sem_wait () from /lib/libpthread.so.0
> #3  0x10016428 in main (argc=2, argv=0x7ffffdf4) at main.c:7361
> (gdb) info threads
> (gdb) info sharedlibrary
> From        To          Syms Read   Shared Object Library
> 0x0fe15aa0  0x0ff1dd20  Yes         /lib/libc.so.6
> 0x0fd8d0c0  0x0fd95d2c  Yes         /lib/libpthread.so.0
> 0x30001f60  0x30013980  Yes         /lib/ld.so.1
> 0x0fd6006c  0x0fd67a6c  No          /lib/libnss_files.so.2
> (gdb)
> ######################
>
> Could you tell me why the program is supspended? Is the problem
> in the C library?
>
> I would really appreciate it if anyone could give me some advices.
>
> Thanks.
>
> Best regards,
>
> Albert
>

Re: Program terminated by SIGTRAP in gdb

[Paul Pluzhnikov]

On Wed, Jan 14, 2009 at 4:37 PM, Albert Fu <quarkverse@gmail.com> wrote:

> Program received signal SIGTRAP, Trace/breakpoint trap.

This is happening because GDB did not attach some of the application
threads.

The most frequent causes are:
- libpthread.so.0 is stripped

  What does the command below produce:
   nm /lib/libpthread.so.0 | egrep '_version|threads_events'

- libpthread.so.0 does not match in version libthread_db.so.1

  This may happen if you build your own glibc, but don't install
  all the pieces of it.

Cheers,
-- 
Paul Pluzhnikov

Re: Program terminated by SIGTRAP in gdb

[Albert Fu]

>   What does the command below produce:
>    nm /lib/libpthread.so.0 | egrep '_version|threads_events'
I typed the command and it produced:

0001da70 g __linuxthreads_version
0001da9c s __pthread_threads_events

> This may happen if you build your own glibc, but don't install
> all the pieces of it.
I use all the software from the same Linux release.

Is there any document which describes what gdb can do or can't do
when debugging a multi-threaded program?

Subject:"gdb and multi-threaded (NPTL) programs"
There were some discussions back in March 24, 2006 mentioned
that GDB changes the behavior of a multi-threaded program.
Is there any changes in GDB since then?

Re: Program terminated by SIGTRAP in gdb

[Paul Pluzhnikov]

On Fri, Jan 16, 2009 at 11:05 AM, Albert Fu <quarkverse@gmail.com> wrote:

>>   What does the command below produce:
>>    nm /lib/libpthread.so.0 | egrep '_version|threads_events'

> I typed the command and it produced:
>
> 0001da70 g __linuxthreads_version
> 0001da9c s __pthread_threads_events

Did you do that command on host or on target (or are they one and
the same)?

The target /lib/libpthread.so.0 *must* not be stripped.

Cheers,
-- 
Paul Pluzhnikov

Re: Program terminated by SIGTRAP in gdb

[Paul Pluzhnikov]

[I added gdb@sourceware.org back]

On Fri, Jan 16, 2009 at 3:13 PM, Albert Fu <quarkverse@gmail.com> wrote:

>> Did you do that command on host or on target (or are they one and
>> the same)?
> It produced "No Symbols" when I ran the command on the target.
>
> I guest libpthread.so0 is stripped.

Indeed. I am glad I asked.

> Is there any example to compile a non-stripped version of libpthread?

Your compiled for target version is already likely not stripped.
Possibly you stripped it before copying to target, to save space.

If so, use 'strip --strip-debug' instead of 'strip'.

If your target version is stripped, notify your vendor that
it is "no good".

Rebuilding glibc for target using your cross-compiler will produce
non-stripped version. Beware: libc.so.6, libpthread.so.0,
ld-linux.so.2 etc. etc. must all match! Do not "mix and match"
parts of glibc from different compilations.

Cheers,
-- 
Paul Pluzhnikov