Updated throwable and stacktrace printing patch

Andrew Haley aph@cambridge.redhat.com
Mon Aug 19 07:28:00 GMT 2002

A few nits:

You didn't rebuild Makefile.in.  Or there is no mention of it in your

I'm trying a null pointer exception thrown with

Two bugs:

   at 0x4034a026 (Unknown Source)

Unknown?  It's catch_segv() in libgcj.so.  I'm pretty sure this used
to work, but perhaps this is a bug in dladdr().

   at 0xffffffffbfffe504 (Unknown Source)

There's a sign extension bug here.

   at Throw_2.main(java.lang.String[]) (/cuddles/aph/gcc.clean/gcc.java-inliner/libjava/testsuite/libjava.lang/Throw_2.java:47)

+gnu::gcj::runtime::NameFinder::getAddr(RawData* addrs, jint n)
+  void **p = (void **) addrs;
+  return (jlong) p[n];

It is not legal C++ to convert a pointer to a signed long by means of
a cast.  Please convert the RawData* to hex and return the hex string
instead.  A correct way to do this is the "*p" sprintf option, or by
using a Pmode int and doing it by hand like name-finder.cc did.  This
would also fix the sign extension bug.

We no longer indicate that we have thrown an exception that was caused
by a signal.  It seems that sanitize removes _Jv_ThrowSignal() so you
can't tell what happened.  This is unfortunate.  In the future I
intend to decode signal handler info so that you can see where the
null pointer access occurred.
You could just print <signal>.

What's the point of the equal test?  Of course it would shorten the
ouput for recursive calls but why is this special case necessary?


More information about the Java-patches mailing list