Throwable stack trace printing again

[Andrew Haley <aph at cambridge dot redhat dot com>]

Mark Wielaard writes:
 > Hi,
 > 
 > I rewrote Throwable stack trace (printing) support. With this patch the
 > Junk example mentioned in the Throwable javadoc gives (when compiled
 > with -g):
 > 
 > HighLevelException: MidLevelException: LowLevelException
 >    at Junk.a() (/tmp/Junk.java:21)
 >    at Junk.main(java.lang.String[]) (/tmp/Junk.java:7)
 > Caused by: MidLevelException: LowLevelException
 >    at Junk.c() (/tmp/Junk.java:36)
 >    at Junk.b() (/tmp/Junk.java:29)
 >    at Junk.a() (/tmp/Junk.java:19)
 >    ...1 more
 > Caused by: LowLevelException
 >    at Junk.e() (/tmp/Junk.java:46)
 >    at Junk.d() (/tmp/Junk.java:44)
 >    at Junk.c() (/tmp/Junk.java:34)
 >    ...3 more
 > 
 > The patch tries to accomplish a couple of things:
 > - Simplify and optimize the stack trace printing algorithm which is done
 > by refactoring the code and using a StringBuffer. This also solves the
 > bug I mentioned a couple of days ago which was caused by forgetting to
 > flush the PrintWriter. Now no temporary PrintWriter is created at all.
 > - Separating the VM dependent part from the VM independent part by
 > moving fillInStackTrace() and getStackTrace() into a new package final
 > class VMThrowable. This should make Throwable easier to share with other
 > VMs based on GNU Classpath.
 > - Do as much as possible in java which makes manipulating the
 > StackTraceElement[] that much easier.
 
 > I followed the advise of Bryce and
 > store the raw stack trace as an long[] so only two short native methods
 > are needed.

 > Questions:
 > - Is the separation of Throwable and VMThrowable OK? I had hoped that
 > gcj would inline calls to a final package local class but it currently
 > doesn't.
 > - Is the conversion to/from void*/jlong correct? It works on my
 > i686-pc-linux-gnu and I will try it out on a powerpc-unknown-linux-gnu
 > machine soon, but my C knowledge is not good enough to know if this will
 > always work on any architecture.

It's not ISO standard C, for sure.

I think it's fair enough to store the raw stack trace as an unsigned
long but you're using a jlong.  AFAIK conversion from signed longs to
pointers is not well-defined, bvut in practice this will probably
always be okay.  Clearly there's no Java type that corresponds to a
native pointer.

On the other hand, the Real-Time Specification for Java uses Java
longs as base addresses for physical memory, so I suppose this
objection is irrlevant.  It would surely be better to create a Java
container for a native address, though.

 > - Is doing most things in java a good idea?

I think so.

 > I personally think nicer
 > stack traces are much more important than having working stack traces
 > when the runtime breaks down. And you probably have much bigger problems
 > then having a working printStackTrace(). But I guess not everybody loves
 > using gdb ;)

It's not always possible.  Some embedded systems don't have an
appropriate interface.

 > - OK to commit?

Should the native implementation of VMThrowable really be in
natThrowable.cc?

Did you try it with addr2name.awk?  Without addr2line and c++filt?

Does it cause any regressions with null pointer excpetions and
division by zero?

Andrew.