Bug 121448 - No stack traces when in system calls
No stack traces when in system calls
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Andrew Cagney
:
Depends On: 108892
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-21 13:26 EDT by Gavin Scott
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-16 01:41:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gavin Scott 2004-04-21 13:26:24 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20040319 Galeon/1.3.7

Description of problem:
Stack traces can't be obtained when processes are in system calls.  I
don't know exactly when this broke, but it definitely worked with
kernel-2.6.4-1.305

Version-Release number of selected component (if applicable):
2.6.5-1.332

How reproducible:
Always

Steps to Reproduce:
gavin@marquez tmp]$ cat testsleep.c
#include <stdio.h>
 
void
do_sleep ()
{
  sleep (1);
}
 
void
sleep_alot ()
{
  int i;
 
  for (;;)
    {
      do_sleep ();
    }
}
 
int
main (int argc, char * const argv[])
{
  sleep_alot ();
  return 0;
}
[gavin@marquez tmp]$ gcc -ggdb -o testsleep testsleep.c
[gavin@marquez tmp]$ ./testsleep &
[2] 1905
[gavin@marquez tmp]$ killall -SEGV testsleep

Actual Results:  [gavin@marquez tmp]$ rm core.*
[gavin@marquez tmp]$ uname -a
Linux marquez.ath.cx 2.6.5-1.332 #1 Mon Apr 19 10:13:26 EDT 2004 i686
athlon i386 GNU/Linux
[gavin@marquez tmp]$ ./testsleep &
[1] 2313
[gavin@marquez tmp]$ killall -SEGV testsleep
[gavin@marquez tmp]$ gdb testsleep core.*
GNU gdb Red Hat Linux (6.0post-0.20040223.14rh)
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 "i386-redhat-linux-gnu"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".
 
Core was generated by `./testsleep'.
Program terminated with signal 11, Segmentation fault.
 
warning: svr4_current_sos: Can't read pathname for load map:
Input/output error
 
Error while mapping shared library sections:
: Success.
Error while reading shared library symbols:
: No such file or directory.
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x0065f41a in ?? ()
(gdb) where
#0  0x0065f41a in ?? ()
#1  0xfef54028 in ?? ()
#2  0x00228ffc in ?? () from /lib/tls/libc.so.6
#3  0xfef53e84 in ?? ()
#4  0x00197910 in __nanosleep_nocancel () from /lib/tls/libc.so.6
#5  0x0019775f in sleep () from /lib/tls/libc.so.6
Previous frame inner to this frame (corrupt stack?)
(gdb) quit

Expected Results:  [gavin@marquez tmp]$ rm core.*
[gavin@marquez tmp]$ uname -a
Linux marquez.ath.cx 2.6.4-1.305 #1 Fri Apr 2 13:46:07 EST 2004 i686
athlon i386 GNU/Linux
[gavin@marquez tmp]$ gdb testsleep core.*
Excess command line arguments ignored. (core.1905)
GNU gdb Red Hat Linux (6.0post-0.20040223.14rh)
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 "i386-redhat-linux-gnu"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".
 
 
warning: exec file is newer than core file.
Core was generated by `./testsleep'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x005e47a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) where
#0  0x005e47a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00683910 in __nanosleep_nocancel () from /lib/tls/libc.so.6
#2  0x0068375f in sleep () from /lib/tls/libc.so.6
#3  0x08048380 in do_sleep () at testsleep.c:6
#4  0x08048391 in sleep_alot () at testsleep.c:16
#5  0x080483a8 in main (argc=1, argv=0xfeec9ac4) at testsleep.c:23
(gdb) quit

Additional info:
Comment 1 Elena Zannoni 2004-04-21 15:18:37 EDT
maybe cagney can help a bit with this.
Comment 2 Andrew Cagney 2004-04-21 17:18:33 EDT
What is at 0x0065f41a?  Cating /proc/$PID/maps should at least give a
hint.
Comment 3 Gavin Scott 2004-04-22 14:36:17 EDT
You can find another run including /proc/$PID/maps below.  I just now
noticed the gdb error messages in my run with the 2.6.5 kernel:

warning: svr4_current_sos: Can't read pathname for load map:
Input/output error
 
Error while mapping shared library sections:
: Success.
Error while reading shared library symbols:
: No such file or directory.

which I guess are related to this problem, but I'm unclear as to what
they mean. 

[gavin@marquez tmp]$ uname -a
Linux marquez.ath.cx 2.6.5-1.332 #1 Mon Apr 19 10:13:26 EDT 2004 i686
athlon i386 GNU/Linux
[gavin@marquez tmp]$ rm core.*
[gavin@marquez tmp]$ ./testsleep &
[1] 2325
[gavin@marquez tmp]$ cat /proc/2325/maps
00111000-00227000 r-xp 00000000 03:05 655443     /lib/tls/libc-2.3.3.so
00227000-00229000 r--p 00115000 03:05 655443     /lib/tls/libc-2.3.3.so
00229000-0022b000 rw-p 00117000 03:05 655443     /lib/tls/libc-2.3.3.so
0022b000-0022d000 rw-p 00000000 00:00 0
005e4000-005f9000 r-xp 00000000 03:05 655406     /lib/ld-2.3.3.so
005f9000-005fa000 r--p 00014000 03:05 655406     /lib/ld-2.3.3.so
005fa000-005fb000 rw-p 00015000 03:05 655406     /lib/ld-2.3.3.so
00682000-00683000 r-xp 00000000 00:00 0
08048000-08049000 r-xp 00000000 03:05 213748    
/home/gavin/work/tmp/testsleep
08049000-0804a000 rw-p 00000000 03:05 213748    
/home/gavin/work/tmp/testsleep
f7061000-f7062000 rw-p 00000000 00:00 0
fef4b000-ff000000 rw-p fff55000 00:00 0
ffffd000-ffffe000 ---p 00000000 00:00 0
[gavin@marquez tmp]$ killall -SEGV testsleep
[gavin@marquez tmp]$ gdb testsleep core.*
GNU gdb Red Hat Linux (6.0post-0.20040223.14rh)
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 "i386-redhat-linux-gnu"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".
 
Core was generated by `./testsleep'.
Program terminated with signal 11, Segmentation fault.
 
warning: svr4_current_sos: Can't read pathname for load map:
Input/output error
 
Error while mapping shared library sections:
: Success.
Error while reading shared library symbols:
: No such file or directory.
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x0068241a in ?? ()
(gdb) where
#0  0x0068241a in ?? ()
#1  0xfef4be98 in ?? ()
#2  0x00228ffc in ?? () from /lib/tls/libc.so.6
#3  0xfef4bcf4 in ?? ()
#4  0x00197910 in __nanosleep_nocancel () from /lib/tls/libc.so.6
#5  0x0019775f in sleep () from /lib/tls/libc.so.6
Previous frame inner to this frame (corrupt stack?)
(gdb) quit
Comment 4 Andrew Cagney 2004-04-22 14:58:44 EDT
Arjan,

what's this?

00682000-00683000 r-xp 00000000 00:00 0

It's confusing GDB (vsyscall page?) which is currently been fixed in
mainline.
Comment 5 Arjan van de Ven 2004-04-22 15:04:22 EDT
that's the vsyscall page yes
Comment 6 Andrew Cagney 2004-04-23 13:24:40 EDT
oops, got the dependency backwards :-(
Comment 7 Dave Jones 2005-04-16 01:41:27 EDT
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.

Note You need to log in before you can comment on or make changes to this bug.