On Wed, Mar 14, 2007 at 05:49:22AM +0530, Syed Ahemed wrote:
quoted text
> Hello all.
> I have a tricky problem on  hand and a straight forward question.
> 
> Tricky problem:
> ---------------------
> While debugging a simple multithreaded application using gdb linux
> 2.4.28 , i noticed the thread that has crashed after sigsegv has
> complete information on the gdb (both  address and function at the
> time of crash ) .But the other threads that are in wait state (
> executing glibc functions at the time of crash ) just has the address
> but not the function name as shown below.
> 
> 
> sh-2.05b# ./gdb a.out /mnt/cf/engg_files/core_files/
> a.out.1173437318.core.5312   a.out.1173453940.core.9829
> a.out.1173438125.core.16016  lost+found
> a.out.1173438881.core.18721
> <f/engg_files/core_files/a.out.1173453940.core.9829
> GNU gdb 6.3
> 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 "i686-pc-linux-gnu"...Using host libthread_db 
> library
> "/lib/libthread_db.so.1".
> 
> warning: exec file is newer than core file.
> Core was generated by `./a.out'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /lib/libpthread.so.0...done.
> Loaded symbols for /lib/libpthread.so.0
> Reading symbols from /lib/libc.so.6...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /opt/lib/ld-linux.so.2...done.
> Loaded symbols for /opt//lib/ld-linux.so.2
> #0  0x080485df in a (p=0x0) at threadcore.c:34
> 34      threadcore.c: No such file or directory.
>        in threadcore.c
> (gdb) info threads
>  3 process 10993  0x08053840 in ?? ()
>  2 process 1267  0xbf5ff9d0 in ?? ()
> * 1 process 9829  0x080485df in a (p=0x0) at threadcore.c:34
> (gdb) thread 3
> [Switching to thread 3 (process 10993)]#0  0x08053840 in ?? ()
> (gdb) bt
> #0  0x08053840 in ?? ()
> Cannot access memory at address 0x2b
> (gdb)
> #0  0x08053840 in ?? ()
> Cannot access memory at address 0x2b
> (gdb) thread 1
> [Switching to thread 1 (process 9829)]#0  0x080485df in a (p=0x0)
>    at threadcore.c:34
> 34      in threadcore.c
> (gdb) bt
> #0  0x080485df in a (p=0x0) at threadcore.c:34
> #1  0x080485bc in main () at threadcore.c:21
> (gdb) thread 2
> [Switching to thread 2 (process 1267)]#0  0xbf5ff9d0 in ?? ()
> (gdb) bt
> #0  0xbf5ff9d0 in ?? ()
> Cannot access memory at address 0x2b
> (gdb) q
> sh-2.05b#
> 
> 
> The problem is with the same glibc and gdb , Redhat 9 linux 2.4.20-8
> does  give me complete information of all the threads in the "info
> threads" command.
> Having read similar problems on various mailing lists , i believe the
> only difference is redhat 9 has patched its kernel with NTPL or
> debugging support for linux in the kernel.
> 
> Wanted to confirm if it this correct .

I really have no idea about this problem.

quoted text
> My question
> ------------------
> 
> Someone would say move to 2.6 kernel and a different glibc,But with
> custom applications at stake .I can't take that risk as yet .So i
> would want an NTPL patch for 2.4.28 kernel
> Where do i get it ? Please do respond .

Last time I saw an NPTL patch, it was for something like 2.4.21 patched
with O(1) scheduler. I bet you'll have a hard time merging those together
in 2.4.28. It is also possible that core dumps don't look the same. I
have in mind some old changes about thread core dumps, but that's too
far away to say anything reliable on the subject. Check that your core
files are of the same sizes between NPTL and no-NPTL kernels.

Alternatively, you could try RHEL3's kernel (2.4.21) which has all those
things and which is still supported.

Regards,
Willy

-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/