Bug 137110 - No stack trace w/ threaded objc programs
No stack trace w/ threaded objc programs
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-25 16:15 EDT by Gavin Scott
Modified: 2008-02-15 13:05 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-14 01:01:03 EST
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-10-25 16:15:07 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040922 Epiphany/1.2.7

Description of problem:
I am frequently unable to see complete stack traces when running gdb
on multi-threaded objective-c applications.  Gdb reports "Previous
frame inner to this frame (corrupt stack?)".  I have the relevant
debuginfo rpms installed:

[gavin@hesse tmp]$ rpm -qa | grep debuginfo
glibc-debuginfo-common-2.3.3-27
openssl-debuginfo-0.9.7a-35
glibc-debuginfo-2.3.3-27
gcc-debuginfo-3.3.3-7


Version-Release number of selected component (if applicable):
gcc-3.3.3-7

How reproducible:
Always

Steps to Reproduce:
1.Compile and run the program below.  It will hang forever since it
creates a deadlock.  Attach gdb to it and you won't get a complete
stack trace on thread 1.

# gcc -Wall -ggdb -o badstack badstack.m -lobjc -lpthread

#include <stdlib.h>
#include <objc/thr.h>
#include <objc/Object.h>

objc_mutex_t global_lock;

@interface TestObj : Object
{
  objc_mutex_t lock;
  BOOL ready_p;
}

- (BOOL) isReady;
- (objc_mutex_t) lock;
- doTest:(id) unused;

@end

@implementation TestObj

- doTest:(id) unused
{
  lock = objc_mutex_allocate ();
  objc_mutex_lock (lock);
  ready_p = YES;

  objc_mutex_lock (global_lock);
  /* deadlock */

  return self;
}

- (BOOL) isReady
{
  return ready_p;
}

- (objc_mutex_t) lock
{
  return lock;
}

@end


int
main (int argc, char * const argv[])
{
  objc_thread_t thread;
  TestObj *obj;

  global_lock = objc_mutex_allocate ();
  objc_mutex_lock (global_lock);

  obj = [[TestObj alloc] init];
  thread = objc_thread_detach (@selector (doTest:), obj, nil);
  while (![obj isReady])
    objc_thread_yield ();

  objc_mutex_lock ([obj lock]);
  /* deadlock */

  return 0;
}


Actual Results:  GNU gdb Red Hat Linux (6.0post-0.20040223.19rh)
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".

(gdb) attach 26089
Attaching to program: /home/gavin/tmp/badstack, process 26089
Reading symbols from /usr/lib/libobjc.so.1...Reading symbols from
/usr/lib/debug//usr/lib/libobjc.so.1.0.0.debug...done.
done.
Loaded symbols for /usr/lib/libobjc.so.1
Reading symbols from /lib/tls/libpthread.so.0...Reading symbols from
/usr/lib/debug//lib/tls/libpthread-0.61.so.debug...done.
[Thread debugging using libthread_db enabled]
[New Thread -151076736 (LWP 26089)]
[New Thread -151077968 (LWP 26090)]
done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/libgcc_s.so.1...Reading symbols from
/usr/lib/debug//lib/libgcc_s-3.3.3-20040413.so.1.debug...done.
done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/tls/libc.so.6...Reading symbols from
/usr/lib/debug//lib/tls/libc-2.3.3.so.debug...done.
done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...Reading symbols from
/usr/lib/debug//lib/ld-2.3.3.so.debug...done.
done.
Loaded symbols for /lib/ld-linux.so.2
0x001e27a2 in ?? () at rtld.c:334 from /lib/ld-linux.so.2
Current language:  auto; currently c
(gdb) info threads
  2 Thread -151077968 (LWP 26090)  0x001e27a2 in ?? () at rtld.c:334
   from /lib/ld-linux.so.2
  1 Thread -151076736 (LWP 26089)  0x001e27a2 in ?? () at rtld.c:334
   from /lib/ld-linux.so.2
(gdb) thread 1
[Switching to thread 1 (Thread -151076736 (LWP 26089))]#0  0x001e27a2
in ?? ()
    at rtld.c:334 from /lib/ld-linux.so.2
(gdb) where
#0  0x001e27a2 in ?? () at rtld.c:334 from /lib/ld-linux.so.2
#1  0x00515cbe in ?? ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:57
   from /lib/tls/libpthread.so.0
#2  0x094f30a0 in ?? ()
#3  0x0051aff4 in ?? () from /lib/tls/libpthread.so.0
#4  0x00510e90 in ?? () at allocatestack.c:252 from
/lib/tls/libpthread.so.0
#5  0x00512c84 in ?? () from /lib/tls/libpthread.so.0
#6  0x008c831c in ?? () from /usr/lib/libobjc.so.1
#7  0xfeecae68 in ?? ()
#8  0x008c831c in ?? () from /usr/lib/libobjc.so.1
#9  0x094f3048 in ?? ()
#10 0xf6fec080 in ?? ()
#11 0xfeecae68 in ?? ()
#12 0x008c50ce in __objc_mutex_lock (mutex=0xfffffffc)
    at /usr/src/debug/gcc-3.3.3-20040413/libobjc/thr-objc.c:128
Previous frame identical to this frame (corrupt stack?)
(gdb) thread 2
[Switching to thread 2 (Thread -151077968 (LWP 26090))]#0  0x001e27a2
in ?? ()
    at rtld.c:334 from /lib/ld-linux.so.2
(gdb) where
#0  0x001e27a2 in ?? () at rtld.c:334 from /lib/ld-linux.so.2
#1  0x00515cbe in ?? ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:57
   from /lib/tls/libpthread.so.0
#2  0x094f2c28 in ?? ()
#3  0x0051aff4 in ?? () from /lib/tls/libpthread.so.0
#4  0x00510e90 in ?? () at allocatestack.c:252 from
/lib/tls/libpthread.so.0
#5  0x00512c84 in ?? () from /lib/tls/libpthread.so.0
#6  0x00313780 in ?? () from /lib/tls/libc.so.6
#7  0x00512ae8 in __pthread_mutex_init (mutex=0x0, mutexattr=0x2)
    at pthread_mutex_init.c:36
#8  0x008c50ce in __objc_mutex_lock (mutex=0xfffffffc)
    at /usr/src/debug/gcc-3.3.3-20040413/libobjc/thr-objc.c:128
#9  0x008c484b in objc_mutex_lock (mutex=0x94f18f8)
    at /usr/src/debug/gcc-3.3.3-20040413/libobjc/thr.c:326
#10 0x080486a8 in -[TestObj doTest:] (self=0x94f2f80, _cmd=0x8049bb0, 
    unused=0x0) at badstack.m:27
#11 0x008c4522 in __objc_thread_detach_function (istate=0xfffffffc)
    at /usr/src/debug/gcc-3.3.3-20040413/libobjc/thr.c:106
#12 0x0051098c in start_thread (arg=0xfffffffc) at pthread_create.c:264
#13 0x002b616a in ?? () from /lib/tls/libc.so.6


Expected Results:  Should be able to get a complete stack trace from
thread 1.

Additional info:
Comment 1 Matthew Miller 2005-04-26 11:02:37 EDT
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Comment 2 Jakub Jelinek 2005-07-19 10:44:53 EDT
If you can reproduce this with FC4, please reopen.
Comment 3 Gavin Scott 2005-09-20 17:20:54 EDT
This is still an issue in FC4.  Using the same test program referenced in the
original bug report saved as badstack.m:

[gavin@boll tmp]$ cat /etc/redhat-release
Fedora Core release 4 (Stentz)
[gavin@boll tmp]$ ./badstack&
[1] 20267
[gavin@boll tmp]$ gdb ./badstack 20267
GNU gdb Red Hat Linux (6.3.0.0-1.24rh)
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 "x86_64-redhat-linux-gnu"...Using host libthread_db
library "/lib64/libthread_db.so.1".

Attaching to program: /home/gavin/work/tmp/badstack, process 20267
Reading symbols from /usr/lib64/libobjc.so.1...Reading symbols from
/usr/lib/debug/usr/lib64/libobjc.so.1.0.0.debug...done.
done.
Loaded symbols for /usr/lib64/libobjc.so.1
Reading symbols from /lib64/libpthread.so.0...Reading symbols from
/usr/lib/debug/lib64/libpthread-2.3.5.so.debug...done.
[Thread debugging using libthread_db enabled]
[New Thread 46912497395488 (LWP 20267)]
[New Thread 1084229984 (LWP 20268)]
done.
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libgcc_s.so.1...Reading symbols from
/usr/lib/debug/lib64/libgcc_s-4.0.1-20050727.so.1.debug...done.
done.
Loaded symbols for /lib64/libgcc_s.so.1
Reading symbols from /lib64/libc.so.6...Reading symbols from
/usr/lib/debug/lib64/libc-2.3.5.so.debug...done.
done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from
/usr/lib/debug/lib64/ld-2.3.5.so.debug...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x0000003ac700af18 in ?? () from /lib64/libpthread.so.0
(gdb) thread apply all bt

Thread 2 (Thread 1084229984 (LWP 20268)):
#0  0x0000003ac700af18 in ?? () from /lib64/libpthread.so.0
#1  0x0000000000000000 in ?? ()

Thread 1 (Thread 46912497395488 (LWP 20267)):
#0  0x0000003ac700af18 in ?? () from /lib64/libpthread.so.0
#1  0x00000000004008b9 in -[TestObj isReady] (self=0x0, _cmd=0x0)
    at badstack.m:36
Previous frame inner to this frame (corrupt stack?)
(gdb) quit
The program is running.  Quit anyway (and detach it)? (y or n) y
Detaching from program: /home/gavin/work/tmp/badstack, process 20267
Comment 4 Matthew Miller 2006-07-07 14:43:46 EDT
Moving to FC4 as per comment #3.
Comment 5 Christian Iseli 2007-01-19 19:11:57 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 6 petrosyan 2008-02-14 01:01:03 EST
Fedora Core 4 is not maintained anymore.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.
Comment 7 Gavin Scott 2008-02-15 13:05:59 EST
Just a note that this does indeed work properly in F7.

Current directory is ~/work/tmp/
GNU gdb Red Hat Linux (6.6-16.fc7rh)
Copyright (C) 2006 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 "x86_64-redhat-linux-gnu"...
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) attach 9595
Attaching to program: /home/gavin/work/tmp/badstack, process 9595
Reading symbols from /usr/lib64/libobjc.so.1...done.
Loaded symbols for /usr/lib64/libobjc.so.1
Reading symbols from /lib64/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 46912496268928 (LWP 9595)]
[New Thread 1084229968 (LWP 9596)]
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /lib64/libgcc_s.so.1...done.
Loaded symbols for /lib64/libgcc_s.so.1
Reading symbols from /lib64/libc.so.6...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x7fff58bfd000
0x000000368ca0c808 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0
(gdb) thread apply all bt

Thread 2 (Thread 1084229968 (LWP 9596)):
#0  0x000000368ca0c808 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0
#1  0x000000368ca088bf in _L_mutex_lock_103 () from /lib64/libpthread.so.0
#2  0x000000368ca08353 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000003f380129c0 in __objc_mutex_lock () from /usr/lib64/libobjc.so.1
#4  0x0000003f380123f3 in objc_mutex_lock () from /usr/lib64/libobjc.so.1
#5  0x000000000040083d in -[TestObj doTest:] (self=0x605010, _cmd=0x601500,
unused=0x0) at badstack.m:27
#6  0x0000003f380126a7 in ?? () from /usr/lib64/libobjc.so.1
#7  0x000000368ca062f7 in start_thread () from /lib64/libpthread.so.0
#8  0x000000368aad0fbd in clone () from /lib64/libc.so.6

Thread 1 (Thread 46912496268928 (LWP 9595)):
#0  0x000000368ca0c808 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0
#1  0x000000368ca088bf in _L_mutex_lock_103 () from /lib64/libpthread.so.0
#2  0x000000368ca08353 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000003f380129c0 in __objc_mutex_lock () from /usr/lib64/libobjc.so.1
#4  0x0000003f380123f3 in objc_mutex_lock () from /usr/lib64/libobjc.so.1
#5  0x0000000000400957 in main (argc=1, argv=0x7fff58acbce8) at badstack.m:60
#0  0x000000368ca0c808 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0

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