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 . 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 . Regards -- Syed I'm afraid that I've seen too many people fix bugs by looking at debugger output, and that almost inevitably leads to fixing the symptoms rather than the underlying problems. --Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/