This GDB was configured as "s390-redhat-linux"... (no debugging symbols found)... [New Thread 1024 (LWP 18236)] /var/log/squid/gdb.in:3: Error in sourced command file: Cannot find user-level thread for LWP 18236: generic error >From googling, looks like this might be a glibc bug? The gdb.in has: handle SIGPIPE pass nostop noprint handle SIGTRAP pass nostop noprint run -DNYCd3 backtrace Quit I've tried with the glibc-2.2.4-24.2s.1 RPMS precompiled for s390, and also from a rebuilt glibc-2.2.4-32.src.rpm available in the 7.2/en/os/SRPMS updates directory. Has anyone else seen this for multi-threaded apps on RH 7.2? ~ Daniel > -----Original Message----- > From: Jarboe, Daniel - Data Center Operations > <daniel.jarboe@xxxxxxxxxxxx> > Sent: Tuesday, August 26, 2003 7:21 AM > To: LINUX-390@xxxxxxxxxxxxx > Subject: Gdb on s/390 > > > I've been trying to hunt down a squid bug, and my > unfamiliarity with gdb > is hindering documentation gathering for the squid developers. > > I'm getting the userprocess_debug messages: > Aug 20 06:14:58 linprox kernel: User process fault: interruption code > 0x10 > Aug 20 06:14:58 linprox kernel: failing address: 1010000 > Aug 20 06:14:58 linprox kernel: CPU: 0 > Aug 20 06:14:58 linprox kernel: Process squid (pid: 27582, > stackpage=08C39000) > Aug 20 06:14:58 linprox kernel: > Aug 20 06:14:58 linprox kernel: User PSW: 070dd000 c02b601e > Tainted: PF > Aug 20 06:14:58 linprox kernel: task: 08c38000 ksp: 08c39cf8 pt_regs: > 08c39f68 > Aug 20 06:14:58 linprox kernel: User GPRS: > Aug 20 06:14:58 linprox kernel: 0091c110 00000003 01010101 000dc6e8 > Aug 20 06:14:58 linprox kernel: 01010101 4035cb50 00000000 7fffd348 > Aug 20 06:14:58 linprox kernel: 01010101 00000000 00000000 7fffcc58 > Aug 20 06:14:58 linprox kernel: c03601ec c02b5ffc c02827ce 7fffcc58 > Aug 20 06:14:58 linprox kernel: User ACRS: > Aug 20 06:14:58 linprox kernel: 40177f60 00000000 00000000 00000000 > Aug 20 06:14:58 linprox kernel: 00000000 00000000 00000000 00000000 > Aug 20 06:14:58 linprox last message repeated 2 times > Aug 20 06:14:58 linprox kernel: User Code: > Aug 20 06:14:58 linprox kernel: bf 31 20 00 a7 84 00 1c a7 2a 00 01 18 > 32 14 31 > a7 74 ff f8 > Aug 20 06:14:58 linprox squid[26622]: Squid Parent: child > process 27821 > started > > Often repeatedly, as squid restarts itself. > > > Gdb of the dumped core showed: > This GDB was configured as "s390-redhat-linux"... > (no debugging symbols found)... > Core was generated by `(squid) -D'. > Program terminated with signal 6, Aborted. > Reading symbols from /lib/libcrypt.so.1...done. > Loaded symbols for /lib/libcrypt.so.1 > Reading symbols from /lib/libssl.so.2...done. > Loaded symbols for /lib/libssl.so.2 > Reading symbols from /lib/libcrypto.so.2...done. > Loaded symbols for /lib/libcrypto.so.2 > Reading symbols from /lib/libpthread.so.0...done. > > warning: Unable to set global thread event mask: generic error > [New Thread 1024 (LWP 16999)] > Error while reading shared library symbols: > Cannot enable thread event reporting for Thread 1024 (LWP 16999): > generic error > Reading symbols from /lib/librt.so.1...done. > Loaded symbols for /lib/librt.so.1 > Reading symbols from /lib/libm.so.6...done. > Loaded symbols for /lib/libm.so.6 > Reading symbols from /lib/libresolv.so.2...done. > Loaded symbols for /lib/libresolv.so.2 > Reading symbols from /lib/libnsl.so.1...done. > Loaded symbols for /lib/libnsl.so.1 > Reading symbols from /lib/libc.so.6...done. > Loaded symbols for /lib/libc.so.6 > Reading symbols from /lib/ld.so.1...done. > Loaded symbols for /lib/ld.so.1 > Reading symbols from /lib/libnss_files.so.2...done. > Loaded symbols for /lib/libnss_files.so.2 > #0 0x4025f9de in kill () at soinit.c:56 > 56 soinit.c: No such file or directory. > in soinit.c > (gdb) bt > #0 0x4025f9de in kill () at soinit.c:56 > #1 0x4016f360 in raise (sig=6) at signals.c:65 > #2 0x40261124 in abort () at ../sysdeps/generic/abort.c:88 > #3 0x004967e2 in strcpy () at soinit.c:56 > (gdb) q > > At this point the develpers suggested I start squid from within gdb to > get a complete backtrace and that was where the real problems began. > > As per the FAQ I ran gdb squid with these gdb commands: > handle SIGPIPE pass nostop noprint > run -DNYCd3 > backtrace > quit > > And just got: > This GDB was configured as "s390-redhat-linux"... > (no debugging symbols found)... > (gdb) Starting program: /usr/sbin/squid -D > [New Thread 1024 (LWP 8641)] > > Program received signal SIGTRAP, Trace/breakpoint trap. > [Switching to Thread 1024 (LWP 8641)] > 0x00000000 in ?? () > (gdb) #0 0x00000000 in ?? () > > Here the squid developers said this was unusual, and did not > happen for > lintel. He suggested trying to handle the SIGTRAP handle the same way > as the SIGPIPE, but when I tried an input file of : > handle SIGPIPE pass nostop noprint > handle SIGTRAP pass nostop noprint > run -DNYCd3 > backtrace > Quit > > I just got: > This GDB was configured as "s390-redhat-linux"... > (no debugging symbols found)... > [New Thread 1024 (LWP 18236)] > /var/log/squid/gdb.in:3: Error in sourced command file: > Cannot find user-level thread for LWP 18236: generic error > > Does anyone see what's going wrong? This is with RH 7.2. > Thanks, > ~ Daniel > > > > > > > > > > ----------------------------------------------------------------------- This message is the property of Time Inc. or its affiliates. It may be legally privileged and/or confidential and is intended only for the use of the addressee(s). No addressee should forward, print, copy, or otherwise reproduce this message in any manner that would allow it to be viewed by any individual not originally listed as a recipient. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is strictly prohibited. If you have received this communication in error, please immediately notify the sender and delete this message. Thank you. _______________________________________________ Redhat-s390-list mailing list Redhat-s390-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/redhat-s390-list
