libgcj/1369: Throwable.printStackTrace() isn't working
bryce@albatross.co.nz
bryce@albatross.co.nz
Wed Dec 20 12:25:00 GMT 2000
>Number: 1369
>Category: libgcj
>Synopsis: Throwable.printStackTrace() isn't working
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bryce
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Dec 20 12:19:19 PST 2000
>Closed-Date: Mon Oct 09 17:36:37 PDT 2000
>Last-Modified: Mon Oct 9 17:40:02 PDT 2000
>Originator: Bryce McKinlay
>Release: gcc version 2.96 20000905 (experimental)
>Organization:
>Environment:
Redhat 7.0 beta:
glibc-2.1.91-18
binutils-2.10.0.18-1
>Description:
I noticed that libgcj's stack trace doesn't seem to be
working properly anymore. This is probibly something to
do with the recent glibc or binutils I'm running.
public class StackTrace
{
public static void main (String[] args) { a(); }
static void a() { b(); }
static void b() { c(); }
static void c() { Thread.dumpStack(); }
}
gets:
$ ./st
java.lang.Exception: Stack trace
at 0x401d500a: java::lang::Throwable::Throwable(java::lang::String *) (/usr/l
ocal/gcc/lib/libgcj.so.1)
at 0x401c8f12: java::lang::Exception::Exception(java::lang::String *) (/usr/l
ocal/gcc/lib/libgcj.so.1)
at 0x401d2381: java::lang::Thread::dumpStack(void) (/usr/local/gcc/lib/libgcj
.so.1)
at 0x0804b8ab: __frame_state_for (./st)
at 0x0804b88b: __frame_state_for (./st)
at 0x0804b86b: __frame_state_for (./st)
at 0x0804b84b: __frame_state_for (./st)
at 0x40238d69: gnu::gcj::runtime::FirstThread::run(void) (/usr/local/gcc/lib/
libgcj.so.1)
at 0x4024360a: java::lang::Thread::run_(java::lang::Object *) (/usr/local/gcc
/lib/libgcj.so.1)
at 0x40254b25: _Jv_ThreadSetPriority(_Jv_Thread_t *, int) (/usr/local/gcc/lib
/libgcj.so.1)
at 0x403c664a: GC_start_routine (/usr/local/gcc/lib/libgcjgc.so.1)
at 0x403e0645: pthread_detach (/lib/libpthread.so.0)
at 0x404d53ca: __clone (/lib/libc.so.6)
addr2line gets:
$ addr2line --functions -e ./st 0x0804b8ab
??
/home/bryce/projects/tests/StackTrace.java:6
so it gets the line number right but can't seem to figure
out the symbol name.
>How-To-Repeat:
try running the test case
>Fix:
>Release-Note:
>Audit-Trail:
Formerly PR libgcj/341
Responsible-Changed-From-To: tromey->aph
Responsible-Changed-By: tromey
Responsible-Changed-When: Wed Sep 6 19:13:42 2000
Responsible-Changed-Why:
Andrew handles exception handling.
From: tromey@cygnus.com
To: aph@cygnus.com, bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com,
tromey@cygnus.com
Cc:
Subject: Re: libgcj/341
Date: 7 Sep 2000 02:13:42 -0000
Synopsis: Throwable.printStackTrace() isn't working
Responsible-Changed-From-To: tromey->aph
Responsible-Changed-By: tromey
Responsible-Changed-When: Wed Sep 6 19:13:42 2000
Responsible-Changed-Why:
Andrew handles exception handling.
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=341&database=java
From: Andrew Haley <aph@redhat.com>
To: tromey@cygnus.com
Cc: bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/341
Date: Thu, 7 Sep 2000 10:18:24 +0100 (BST)
tromey@cygnus.com writes:
> Synopsis: Throwable.printStackTrace() isn't working
>
> Responsible-Changed-From-To: tromey->aph
> Responsible-Changed-By: tromey
> Responsible-Changed-When: Wed Sep 6 19:13:42 2000
> Responsible-Changed-Why:
> Andrew handles exception handling.
>
> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=341&database=java
This looks like a binutils bug, so why is it registered as a gcj PR?
It won't get fixed here. :-)
Andrew.
From: Bryce McKinlay <bryce@albatross.co.nz>
To: Andrew Haley <aph@redhat.com>
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/341
Date: Thu, 05 Oct 2000 14:16:37 +1300
Andrew Haley wrote:
> > http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=341&database=java
>
> This looks like a binutils bug, so why is it registered as a gcj PR?
> It won't get fixed here. :-)
I think its a problem with dladdr(). I've sent a report to glibc-bug:
http://sources.redhat.com/ml/bug-glibc/2000-10/msg00012.html`
[ bryce ]
From: Bryce McKinlay <bryce@albatross.co.nz>
To: aph@cygnus.com, java-gnats@sourceware.cygnus.com
Cc:
Subject: Re: libgcj/341
Date: Thu, 05 Oct 2000 17:00:28 +1300
Bryce McKinlay wrote:
> Andrew Haley wrote:
>
> > > http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=341&database=java
> >
> > This looks like a binutils bug, so why is it registered as a gcj PR?
> > It won't get fixed here. :-)
>
> I think its a problem with dladdr(). I've sent a report to glibc-bug:
>
> http://sources.redhat.com/ml/bug-glibc/2000-10/msg00012.html`
>
Ulrich Drepper claims that dladdr()'s behaviour is correct (however, it seems to
contradict my interpretation of the comment in dlfcn.h)
To fix it, it appears that we need a way to tell if an address is from a shared
object or not. I don't know a way to do that.
regards
[ bryce ]
From: Jeff Sturm <jeff.sturm@appnet.com>
To: Bryce McKinlay <bryce@albatross.co.nz>
Cc: aph@cygnus.com, java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/341
Date: Thu, 05 Oct 2000 09:13:13 -0400
Bryce McKinlay wrote:
> Ulrich Drepper claims that dladdr()'s behaviour is correct (however, it seems to
> contradict my interpretation of the comment in dlfcn.h)
FWIW the new dladdr() is compatible with Solaris. The comment in dlfcn.h
appears out of date.
Actually, if dladdr() does the right thing, we may no longer need addr2line on
Linux, which is a good thing...
> To fix it, it appears that we need a way to tell if an address is from a shared
> object or not. I don't know a way to do that.
It appears something is broken in dladdr() anyway. The a,b,c methods should
have global symbols, so dladdr() isn't resolving to the closest symbol, it falls
all the way down to __frame_state_for instead.
A glibc bug report may still be appropriate.
What does a "nm ./st | sort" look like on RH 7?
(As a workaround, you could compare the symbol to the address of data_start.
Lower addresses cannot be in a shared object.)
--
Jeff Sturm
jeff.sturm@commerceone.com
From: Bryce McKinlay <bryce@albatross.co.nz>
To: Jeff Sturm <jeff.sturm@appnet.com>
Cc: aph@cygnus.com, java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/341
Date: Fri, 06 Oct 2000 12:48:54 +1300
Jeff Sturm wrote:
> Bryce McKinlay wrote:
> > Ulrich Drepper claims that dladdr()'s behaviour is correct (however, it seems to
> > contradict my interpretation of the comment in dlfcn.h)
>
> FWIW the new dladdr() is compatible with Solaris. The comment in dlfcn.h
> appears out of date.
>
> Actually, if dladdr() does the right thing, we may no longer need addr2line on
> Linux, which is a good thing...
dladdr() can't give us source file names or line numbers, so addr2line is still
necessary. I was actually thinking of changing it to always use addr2line - currently
we don't get a line number if the address is inside libgcj.so or another shared object.
addr2line is also nice in that it does automatic demangling. With the new ABI, it
should even automatically do java-style demangling for java code. Cool! Alternatively
if we wanted to avoid the fork, we could link bfd directly.
Of course dladdr() is still needed to figure out which object the address comes from,
and to find the base address of that object.
> > To fix it, it appears that we need a way to tell if an address is from a shared
> > object or not. I don't know a way to do that.
>
> It appears something is broken in dladdr() anyway. The a,b,c methods should
> have global symbols, so dladdr() isn't resolving to the closest symbol, it falls
> all the way down to __frame_state_for instead.
Thats what I thought, but Ulrich's terse reply implied that the "__frame_state_for"
result is expected and has some sort of cosmic significance. To me, dladdr()'s
behaviour is not useful in this case.
> A glibc bug report may still be appropriate.
>
> What does a "nm ./st | sort" look like on RH 7?
$ nm ./st | sort | more
08048ed0 ? _init
08049160 T _start
08049184 t gcc2_compiled.
08049190 t __do_global_dtors_aux
[...]
0804b270 t execute_cfa_insn
0804b6d0 T __frame_state_for
0804b870 T __10StackTrace
0804b890 T main__10StackTracePt6JArray1ZPQ34java4lang6String
0804b8b0 T a__10StackTrace
0804b8d0 T b__10StackTrace
0804b8f0 T c__10StackTrace
[...]
> (As a workaround, you could compare the symbol to the address of data_start.
> Lower addresses cannot be in a shared object.)
Thanks - Presumably, this is portable (enough?)?
regards
[ bryce ]
From: Jeff Sturm <jeff.sturm@appnet.com>
To: Bryce McKinlay <bryce@albatross.co.nz>
Cc: aph@cygnus.com, java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/341
Date: Fri, 06 Oct 2000 10:36:20 -0400
Bryce McKinlay wrote:
> > It appears something is broken in dladdr() anyway. The a,b,c methods should
> > have global symbols, so dladdr() isn't resolving to the closest symbol, it falls
> > all the way down to __frame_state_for instead.
>
> Thats what I thought, but Ulrich's terse reply implied that the "__frame_state_for"
> result is expected and has some sort of cosmic significance. To me, dladdr()'s
> behaviour is not useful in this case.
It's also wrong:
> $ nm ./st | sort | more
> 08048ed0 ? _init
> 08049160 T _start
> 08049184 t gcc2_compiled.
> 08049190 t __do_global_dtors_aux
> [...]
> 0804b270 t execute_cfa_insn
> 0804b6d0 T __frame_state_for
> 0804b870 T __10StackTrace
> 0804b890 T main__10StackTracePt6JArray1ZPQ34java4lang6String
> 0804b8b0 T a__10StackTrace
> 0804b8d0 T b__10StackTrace
> 0804b8f0 T c__10StackTrace
The PR says:
> at 0x0804b8ab: __frame_state_for (./st)
There are two other global symbols between that address and that symbol,
according to the output of "nm". The dladdr() function is intended to return
the nearest symbol to the given address, if it is a valid address at all.
My guess is that dladdr() misses a__10StackTrace etc. because they aren't
referenced outside this module, so the dynamic linker doesn't have to do
anything with them.
It would be nice to have a simple test case for this. I'm not running RH 7,
yet...
--
Jeff Sturm
jeff.sturm@commerceone.com
From: bryce@sourceware.cygnus.com
To: java-gnats@sources.redhat.com
Cc:
Subject: libgcj/341
Date: 9 Oct 2000 01:54:51 -0000
CVSROOT: /cvs/java
Module name: libgcj
Changes by: bryce@sourceware.cygnus.com 2000-10-08 18:54:51
Modified files:
libjava : ChangeLog name-finder.cc
libjava/include: jvm.h
Log message:
2000-10-09 Bryce McKinlay <bryce@albatross.co.nz>
* include/jvm.h: Enable __builtin_expect().
* name-finder.cc (lookup): Don't trust dladdr() if the address is from
the main program. Fix for PR libgcj/341.
Patches:
http://gcc.gnu.org/cgi-bin/gcc/libjava/ChangeLog.diff?cvsroot=java&r1=1.509&r2=1.510
http://gcc.gnu.org/cgi-bin/gcc/libjava/name-finder.cc.diff?cvsroot=java&r1=1.4&r2=1.5
http://gcc.gnu.org/cgi-bin/gcc/libjava/include/jvm.h.diff?cvsroot=java&r1=1.30&r2=1.31
Responsible-Changed-From-To: aph->bryce
Responsible-Changed-By: bryce
Responsible-Changed-When: Mon Oct 9 17:36:37 2000
Responsible-Changed-Why:
I fixed it
State-Changed-From-To: open->closed
State-Changed-By: bryce
State-Changed-When: Mon Oct 9 17:36:37 2000
State-Changed-Why:
I checked in a patch that works around the dladdr() problem.
From: bryce@albatross.co.nz
To: aph@cygnus.com, bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com
Cc:
Subject: Re: libgcj/341
Date: 10 Oct 2000 00:36:37 -0000
Synopsis: Throwable.printStackTrace() isn't working
Responsible-Changed-From-To: aph->bryce
Responsible-Changed-By: bryce
Responsible-Changed-When: Mon Oct 9 17:36:37 2000
Responsible-Changed-Why:
I fixed it
State-Changed-From-To: open->closed
State-Changed-By: bryce
State-Changed-When: Mon Oct 9 17:36:37 2000
State-Changed-Why:
I checked in a patch that works around the dladdr() problem.
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=341&database=java
>Unformatted:
More information about the Gcc-prs
mailing list