thread debugging problem

thread debugging problem

[Andreas Westin]

Hi,

I'm trying to debug a multithreaded program in linux, but I'm not able 
to get any kind of thread info while running the program in gdb.
I've tested with gdb 5.3, 5.3.91 and cvs from yesterday (10th) not any 
of them works.
info thread shows nothing and the program stops with signal 32 when a 
new thread starts.

I'm using Trustix 2.0 with gcc 3.3 and glibc 2.3.2.

Any help is appreciated.

/Andreas

Re: thread debugging problem

[Elena Zannoni]

Andreas Westin writes:
 > Hi,
 > 
 > I'm trying to debug a multithreaded program in linux, but I'm not able 
 > to get any kind of thread info while running the program in gdb.
 > I've tested with gdb 5.3, 5.3.91 and cvs from yesterday (10th) not any 
 > of them works.
 > info thread shows nothing and the program stops with signal 32 when a 
 > new thread starts.
 > 

Hmmm, this usually indicates that there is no thread support
available.  Maybe the version of the Kernel you are using has some
missing pieces. How about glibc-kernheaders?

Do you get a message at gdb startu saying something about using libthread_db?

 > I'm using Trustix 2.0 with gcc 3.3 and glibc 2.3.2.
 > 

Not sure what Trustix is.
But those versions seem roughly ok.

Can you post a gdb session?

elena

 > Any help is appreciated.
 > 
 > /Andreas

Re: thread debugging problem

[Andreas Westin]

>  > Hi,
>  > 
>  > I'm trying to debug a multithreaded program in linux, but I'm not
> able 
>  > to get any kind of thread info while running the program in gdb.
>  > I've tested with gdb 5.3, 5.3.91 and cvs from yesterday (10th) not
> any 
>  > of them works.
>  > info thread shows nothing and the program stops with signal 32 when a
> 
>  > new thread starts.
>  > 
> 
> Hmmm, this usually indicates that there is no thread support
> available.  Maybe the version of the Kernel you are using has some
> missing pieces. How about glibc-kernheaders?
> 
> Do you get a message at gdb startu saying something about using
> libthread_db?
> 
>  > I'm using Trustix 2.0 with gcc 3.3 and glibc 2.3.2.
>  > 
> 
> Not sure what Trustix is.
> But those versions seem roughly ok.
> 
> Can you post a gdb session?
> 

This is the kernel installed.
root@labb ~# uname -a
Linux labb.mobilecity.nu 2.4.21-13trfirewall #1 Thu Jul 10 15:57:32 CEST 2003 
i686 unknown unknown GNU/Linux

I have installed the glibc-devel rpms so the headers should be included.

Trustix is small firewall/gateway dist, http://www.trustix.net/

A sample gdb session, I do not see any message about libthread_db though.

This GDB was configured as "i686-pc-linux-gnu".
(gdb) file .libs/oasis
Reading symbols from .libs/oasis...done.
(gdb) run -f -d -F
Starting program: /usr/local/src/oasis-1.0/src/.libs/oasis -f -d -F
oasis version 1.0
Copyright (c) 2002, Royal Institute of Technology. All rights reserved.

parsing configuration file /usr/local/etc/oasis.conf...
09:06:25 oasis[16384/23845]: initializing...
09:06:25 oasis[16384/23845]: registered probe library libprobe_arping.so for 
domain BOGUS.COM
09:06:25 oasis[16384/23845]: resetting firewall on domain BOGUS.COM
09:06:25 oasis[16384/23845]: spawned /usr/local/sbin/oasis-firewall-sample
[23847]
09:06:25 oasis[16384/23845]: /usr/local/sbin/oasis-firewall-sample[23847] 
returned status 0

Program received signal SIG32, Real-time event 32.
0x401c42cc in sigsuspend () from /lib/libc.so.6
(gdb) 09:06:25 oasis[16386/23851]: monitoring thread starting

(gdb) info thread
(gdb) thread 1
Thread ID 1 not known.


/Andreas

Re: thread debugging problem

[Daniel Jacobowitz]

On Fri, Sep 12, 2003 at 09:15:01AM +0200, Andreas Westin wrote:
> >  > Hi,
> >  > 
> >  > I'm trying to debug a multithreaded program in linux, but I'm not
> > able 
> >  > to get any kind of thread info while running the program in gdb.
> >  > I've tested with gdb 5.3, 5.3.91 and cvs from yesterday (10th) not
> > any 
> >  > of them works.
> >  > info thread shows nothing and the program stops with signal 32 when a
> > 
> >  > new thread starts.
> >  > 
> > 
> > Hmmm, this usually indicates that there is no thread support
> > available.  Maybe the version of the Kernel you are using has some
> > missing pieces. How about glibc-kernheaders?
> > 
> > Do you get a message at gdb startu saying something about using
> > libthread_db?
> > 
> >  > I'm using Trustix 2.0 with gcc 3.3 and glibc 2.3.2.
> >  > 
> > 
> > Not sure what Trustix is.
> > But those versions seem roughly ok.
> > 
> > Can you post a gdb session?
> > 
> 
> This is the kernel installed.
> root@labb ~# uname -a
> Linux labb.mobilecity.nu 2.4.21-13trfirewall #1 Thu Jul 10 15:57:32 CEST 2003 
> i686 unknown unknown GNU/Linux
> 
> I have installed the glibc-devel rpms so the headers should be included.
> 
> Trustix is small firewall/gateway dist, http://www.trustix.net/
> 
> A sample gdb session, I do not see any message about libthread_db though.

Does trustix even ship /lib/libthread_db.so.1?  If not, thread
debugging won't work.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: thread debugging problem

[Andreas Westin]

> On Fri, Sep 12, 2003 at 09:15:01AM +0200, Andreas Westin wrote:
> > >  > Hi,
> > >  > 
> > >  > I'm trying to debug a multithreaded program in linux, but I'm
> not
> > > able 
> > >  > to get any kind of thread info while running the program in
> gdb.
> > >  > I've tested with gdb 5.3, 5.3.91 and cvs from yesterday (10th)
> not
> > > any 
> > >  > of them works.
> > >  > info thread shows nothing and the program stops with signal 32
> when a
> > > 
> > >  > new thread starts.
> > >  > 
> > > 
> > > Hmmm, this usually indicates that there is no thread support
> > > available.  Maybe the version of the Kernel you are using has some
> > > missing pieces. How about glibc-kernheaders?
> > > 
> > > Do you get a message at gdb startu saying something about using
> > > libthread_db?
> > > 
> > >  > I'm using Trustix 2.0 with gcc 3.3 and glibc 2.3.2.
> > >  > 
> > > 
> > > Not sure what Trustix is.
> > > But those versions seem roughly ok.
> > > 
> > > Can you post a gdb session?
> > > 
> > 
> > This is the kernel installed.
> > root@labb ~# uname -a
> > Linux labb.mobilecity.nu 2.4.21-13trfirewall #1 Thu Jul 10 15:57:32
> CEST 2003 
> > i686 unknown unknown GNU/Linux
> > 
> > I have installed the glibc-devel rpms so the headers should be
> included.
> > 
> > Trustix is small firewall/gateway dist, http://www.trustix.net/
> > 
> > A sample gdb session, I do not see any message about libthread_db
> though.
> 
> Does trustix even ship /lib/libthread_db.so.1?  If not, thread
> debugging won't work.

Yes, i have libthread_db_so.1 in /lib

/Andreas

Re: thread debugging problem

[Andrew Cagney]

>> > 
>> > Trustix is small firewall/gateway dist, http://www.trustix.net/
>> > 
>> > A sample gdb session, I do not see any message about libthread_db
> 
>> though.
>> 
>> Does trustix even ship /lib/libthread_db.so.1?  If not, thread
>> debugging won't work.
> 
> 
> Yes, i have libthread_db_so.1 in /lib

But GDB isn't loading it :-(  If it was (with a current [native] GDB) 
you would see a message indicating it had been loaded.

Suggest checking that your gdb includes thread-db.o:thread_db_load, set 
a breakpoint on that and see what happens.

Andrew

Re: thread debugging problem

[Andreas Westin]

> But GDB isn't loading it :-(  If it was (with a current [native] GDB) 
> you would see a message indicating it had been loaded.
> 
> Suggest checking that your gdb includes thread-db.o:thread_db_load, set
> 
> a breakpoint on that and see what happens.

I've switched to redhat9 and now I get thread info, but I'm having other
problems instead. Strange behaviour which I believe shouldn't happen.
When I step forward in the code it seems to be running into somekind of loop
running the same lines of code several times when it shouldn't, as you can see
in the gdb session below. This is with gdb 5.3.91 but I saw the same behaviour
with 5.3 on my gentoo box at home.

Any thoughts ?

Breakpoint 3, monitor_thread_main (arg=0x0) at monitor.c:481
481         if(prio->first)
(gdb) print prio->first
$10 = (struct listitem_t *) 0x805a7f8
(gdb) print prio->first->data
$11 = (void *) 0x8059be8
(gdb) n
480                     next_probe.tv_sec += cfg_getint(cfg, "probe-interval");
(gdb)
481         if(prio->first)
(gdb)
480                     next_probe.tv_sec += cfg_getint(cfg, "probe-interval");
(gdb)
481         if(prio->first)
(gdb) list 480
475                      * the time for the next probe session, otherwise wait a
                                                                           nd go
476                      * on with the next probe session.
477                      */
478
479                     gettimeofday(&next_probe, 0);
480                     next_probe.tv_sec += cfg_getint(cfg, "probe-interval");
481         if(prio->first)
482           logmsg(LOG_ERR, "Ja: %d", timercmp(&((userdata_t*)prio->first->dat
                                                                          
a)->tv, &next_probe, <=));
483                     while(prio->first && timercmp(&((userdata_t*)prio->first
                                                                          
->data)->tv, &next_probe, <=))
484                     {
(gdb)


/Andreas

Re: thread debugging problem

[Michael Elizabeth Chastain]

aw> I've switched to redhat9 and now I get thread info, but I'm having other
aw> problems instead. Strange behaviour which I believe shouldn't happen.
aw> When I step forward in the code it seems to be running into somekind of
aw> loop running the same lines of code several times when it shouldn't, as
aw> you can see in the gdb session below. This is with gdb 5.3.91 but I saw
aw> the same behaviour with 5.3 on my gentoo box at home.

This is normal gdb behavior when the code is optimized
(compiled with -O or -O1 or -O2 or -O3).  The compiler interleaves
instructions from different source lines to improve performance.
You can get used to it, which takes a few days, or you can
compile your code with -O0 and get simpler "next" behavior
at the cost of more object code.

Michael C