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
patch.

I'm trying a null pointer exception thrown with
gnu.gcj.runtime.NameFinder.remove_unknown=false.

Two bugs:

java.lang.NullPointerException
   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)

+jlong
+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?

Andrew.



More information about the Java-patches mailing list