Program no longer exists [SOLVED]

Program no longer exists [SOLVED]

[Alvin Beach]

Hello all,

I don't know why or how, but after I installed gdb-debuginfo-6.3-14 I can now 
debug threaded applications.

I thought I'd send this out in case someone else has run into the same problem 
I did.

Alvin

-- 
Please reply to the list.

debugging threaded apps. thread ID missing in corefile.

[Manoj Iyer]

Regarding debugging threaded apps, gdb does not display the pthread id (ID
returned by pthread_self() ) when reading information from a corefile.

GNU gdb 6.3.50.20050504-cvs
Copyright 2004 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 "powerpc64-unknown-linux-gnu"...Using host
libthread_
db library "/lib/tls/libthread_db.so.1".

Core was generated by `./test'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/tls/libpthread.so.0...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld.so.1...done.
Loaded symbols for /lib/ld.so.1
#0  0x100007c4 in whackthestack () at test.c:76
76              *(int*)0xdeaddead = 0;     /* uncomment to test signal
handler *
/
(gdb) thread
[Current thread is 1 (process 9623)]
(gdb) thread 2
[Switching to thread 2 (process 9628)]#0  0x0ff15a64 in
__nanosleep_nocancel ()
   from /lib/tls/libc.so.6
(gdb)

Where as when debugging the program live it is able to display the pthread
id (I dont know why the ID is a negative number, could be a bug?).

GNU gdb 6.3.50.20050504-cvs
Copyright 2004 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 "powerpc64-unknown-linux-gnu"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) br callme
Breakpoint 1 at 0x10000838: file test.c, line 83.
(gdb) r
Starting program: /home/manjo/projects/zlinux/test64
[Thread debugging using libthread_db enabled]
[New Thread -134270944 (LWP 10491)]
[New Thread -134273824 (LWP 10494)]
[Switching to Thread -134273824 (LWP 10494)]

Breakpoint 1, callme (me=0, i=0) at test.c:83
83              tid = pthread_self();
(gdb) thread 2
[Switching to thread 2 (Thread -134273824 (LWP 10494))]#0  callme (me=0,
i=0)
    at test.c:83
83              tid = pthread_self();


So the question really is, is GDB not reading the thread id from core or
the kernel not dumping r2/r13 (ppc) (address of the struct pthread) to the
core?

Thanks
-----
manjo
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Cogito ergo sum                                                          +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

On Mon, 6 Jun 2005, Alvin Beach wrote:

> Hello all,
>
> I don't know why or how, but after I installed gdb-debuginfo-6.3-14 I can now
> debug threaded applications.
>
> I thought I'd send this out in case someone else has run into the same problem
> I did.
>
> Alvin
>
> --
> Please reply to the list.
>

Re: debugging threaded apps. thread ID missing in corefile.

[Daniel Jacobowitz]

Please don't reply to unrelated messages to post to the list.

On Mon, Jun 06, 2005 at 05:33:09PM -0500, Manoj Iyer wrote:
> 
> Regarding debugging threaded apps, gdb does not display the pthread id (ID
> returned by pthread_self() ) when reading information from a corefile.

Yes.  You can find information about this decision in the list
archives.  We need to use libthread_db.so.1 to retrieve thread IDs, and
we do not have a graceful way to use it for only core dumps which
belong to the native system (as opposed to sysrooted or cross core
dumps).

> Where as when debugging the program live it is able to display the pthread
> id (I dont know why the ID is a negative number, could be a bug?).

Not really.  The ID is a pointer above 0x80000000, used by the
implementation.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Program no longer exists [UNSOLVED]

[Alvin Beach]

On Monday 06 June 2005 19:29, Alvin Beach wrote:
> Hello all,
>
> I don't know why or how, but after I installed gdb-debuginfo-6.3-14 I can
> now debug threaded applications.
>
> I thought I'd send this out in case someone else has run into the same
> problem I did.
>
> Alvin

Sorry list. I spoke too soon. It's really intermitant behaviour. Sometimes I 
can debug and sometimes I get the "Process no longer exists" message.

Again, I apologise.

Alvin

-- 
Please reply to the list.

Re: debugging threaded apps. thread ID missing in corefile.

[Eli Zaretskii]

> Date: Mon, 6 Jun 2005 20:09:44 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com
> 
> On Mon, Jun 06, 2005 at 05:33:09PM -0500, Manoj Iyer wrote:
> > 
> > Regarding debugging threaded apps, gdb does not display the pthread id (ID
> > returned by pthread_self() ) when reading information from a corefile.
> 
> Yes.  You can find information about this decision in the list
> archives.  We need to use libthread_db.so.1 to retrieve thread IDs, and
> we do not have a graceful way to use it for only core dumps which
> belong to the native system (as opposed to sysrooted or cross core
> dumps).

If this situation is not going to be changed RSN, I suggest to say
this in the manual.  Any objections?

Btw, the node "Threads" in the manual sounds at least a little
outdated: e.g., it only mentions Solaris and HP-UX as platforms
capable of supporting multi-threaded debuggees.  Could someone in the
know please read that node and see if it needs to be updated in any
significant way?

> > Where as when debugging the program live it is able to display the pthread
> > id (I dont know why the ID is a negative number, could be a bug?).
> 
> Not really.  The ID is a pointer above 0x80000000, used by the
> implementation.

Well, then perhaps we should display the thread ID in hex?

Re: debugging threaded apps. thread ID missing in corefile.

[Daniel Jacobowitz]

On Tue, Jun 07, 2005 at 06:46:13AM +0300, Eli Zaretskii wrote:
> > Date: Mon, 6 Jun 2005 20:09:44 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb@sources.redhat.com
> > 
> > On Mon, Jun 06, 2005 at 05:33:09PM -0500, Manoj Iyer wrote:
> > > 
> > > Regarding debugging threaded apps, gdb does not display the pthread id (ID
> > > returned by pthread_self() ) when reading information from a corefile.
> > 
> > Yes.  You can find information about this decision in the list
> > archives.  We need to use libthread_db.so.1 to retrieve thread IDs, and
> > we do not have a graceful way to use it for only core dumps which
> > belong to the native system (as opposed to sysrooted or cross core
> > dumps).
> 
> If this situation is not going to be changed RSN, I suggest to say
> this in the manual.  Any objections?

No objection from me.  I'm not planning to change it, because (a)
thread IDs are mostly cosmetic, and (b) the cross-debugging case is
more important to me than the native case.

> Btw, the node "Threads" in the manual sounds at least a little
> outdated: e.g., it only mentions Solaris and HP-UX as platforms
> capable of supporting multi-threaded debuggees.  Could someone in the
> know please read that node and see if it needs to be updated in any
> significant way?

I just took a look at it; I think it's fine.  It also mentions SGI and
Lynx further down; the Lynx code is I think removed now, but still
serves as a valid example here.

> > > Where as when debugging the program live it is able to display the pthread
> > > id (I dont know why the ID is a negative number, could be a bug?).
> > 
> > Not really.  The ID is a pointer above 0x80000000, used by the
> > implementation.
> 
> Well, then perhaps we should display the thread ID in hex?

Hmm.  I wouldn't object to this.  The number is opaque to the user
code; for LinuxThreads it is an encoded index into an array (usually
between 0 and 64k; the first few threads are numbered around 32k and
16k).  That looks plausible in hex or in decimal.  For NPTL they are
pointers and would look more plausible in hex.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Program no longer exists [SOLVED - 95% sure]

[Alvin Beach]

On Monday 06 June 2005 19:29, Alvin Beach wrote:
> Hello all,
>
> I don't know why or how, but after I installed gdb-debuginfo-6.3-14 I can
> now debug threaded applications.
>
> I thought I'd send this out in case someone else has run into the same
> problem I did.
>
> Alvin

Hello all,

I think I know the cause of this problem (Well I got the answer from the 
linux.development.apps newsgroup).

Turns out the glibc and glibc-devel rpms have missed matched versions!

Suse has a security fix for glibc but not glibc-devel. Once I down-graded 
glibc, I was able to debug again.

-- 
Please reply to the mailing list.

Re: debugging threaded apps. thread ID missing in corefile.

[Mark Kettenis]

   Date: Tue, 7 Jun 2005 09:10:22 -0400
   From: Daniel Jacobowitz <drow@false.org>

   > > Not really.  The ID is a pointer above 0x80000000, used by the
   > > implementation.
   > 
   > Well, then perhaps we should display the thread ID in hex?

   Hmm.  I wouldn't object to this.  The number is opaque to the user
   code; for LinuxThreads it is an encoded index into an array (usually
   between 0 and 64k; the first few threads are numbered around 32k and
   16k).  That looks plausible in hex or in decimal.  For NPTL they are
   pointers and would look more plausible in hex.

The number isn't really opaque to the user.  The numbers have type
`pthread_t' and can be printed by the user when debugging his program.
It's the pthread_t type that is opaque.  Ideally we'd use the the
`pthread_t' type for the formatting of these values.  But AFAIC hex is
a good default.

Mark

Re: Program no longer exists [SOLVED - Completely]

[Alvin Beach]

On Tuesday 07 June 2005 15:46, Alvin Beach wrote:
> On Monday 06 June 2005 19:29, Alvin Beach wrote:
> > Hello all,
> >
> > I don't know why or how, but after I installed gdb-debuginfo-6.3-14 I can
> > now debug threaded applications.
> >
> > I thought I'd send this out in case someone else has run into the same
> > problem I did.
> >
> > Alvin
>
> Hello all,
>
> I think I know the cause of this problem (Well I got the answer from the
> linux.development.apps newsgroup).
>
> Turns out the glibc and glibc-devel rpms have missed matched versions!
>
> Suse has a security fix for glibc but not glibc-devel. Once I down-graded
> glibc, I was able to debug again.

Just in case someone is experiencing this same problem, SuSE has released a 
fix for this. They have patched several rpms, which include:

glibc-i18ndata-2.3.4-23.4
glibc-profile-2.3.4-23.4
glibc-2.3.4-23.4
glibc-locale-2.3.4-23.4
glibc-info-2.3.4-23.4
glibc-devel-2.3.4-23.4
timezone-2.3.4-23.4

So, basically, just do an update and the problem will go away.

-- 
Please reply to the mailing list.