Updated throwable and stacktrace printing patch

Mark Wielaard mark@klomp.org
Sat Aug 24 15:27:00 GMT 2002


On Wed, 2002-08-21 at 20:18, Andrew Haley wrote:
> Bryce McKinlay writes:
>  > 
>  > I believe that for most GCJ users, it is better that the stack trace 
>  > resemble the traditional VM stack trace as closely as possible.
> I'm not sure that I agree with all of this, but I'm pretty sure that
> if it came to a vote I'd lose.  So, I give up.  However, I reserve the
> right to say "I told you so" the first time we have to ask for more
> information that would have been provided by an uncensored stack
> trace!

Note that this was not the primary reason for the patch. As I wrote in
the original patch submission the goals of the patch were:

    - 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.
The sanitizing/censoring of the stack trace in NameFinder.java was added
as an example of that last point. And I do admit that I like the result
since it resembles traditional stack traces. But the actual goal was to
make it easier to tweak the stack trace elements from java, make the VM
dependent and independent parts of Throwable more explicit and optimize
the stack trace algorithm (plus fixing the bug).

>  > It also seems reasonable to display the PC in the 
>  > event that line number information is unavailable. But in the general 
>  > case, the PC is unneccessary information for casual Java developers 
>  > which clutters the stack trace.

If we want to add the addresses to the stack trace when we print them we
can do that by creating a subclass of StackTraceElement that adds a
field holding the hex address string and that overrides the toString()

> "Casual" Java developers?  Are you sure?  :-)
>  > There should certainly be an option to switch on verbose stack traces 
>  > (and in the future we need to do a much better job of documenting 
>  > libgcj's knobs), and perhaps it should be the defualt for embedded 
>  > targets. But by default, I think simple, clean, stack traces should be 
>  > used.
> I disagree, but I bow to the majority.  

You almost convinced me to rename the method and property to censor()
instead of sanitize :) And I have thought long and hard if I could make
the default stack trace less cluttered  but still gcj/cni/C++ like. But
I really don't know enough about signals and C++ runtime/exception
issues to make a better sanitizeStack() method then I have written now.
I hope that the framework that I made is general enough for people to
hack on a better sanitize method later.

> Mark, please check in your patch.

OK. Here is the version I am going to checked in.
It has only two changes from my previous post:

- As you suggested I now use your original code from name-finder.cc to
generate the hex string representing the address.
- Someone on the Classpath mailing list noted that we have to copy the
stack when Throwable.setStackTrace() is called.

2002-08-24  Mark Wielaard <mark@klomp.org>

    * Makefile.am (libgcj_la_SOURCES): Remove name-finder.cc.
    (core_java_source_files): Add VMThrowable.java and NameFinder.java
    (nat_source_files): Remove natThrowable.cc, add natVMThrowable.cc
    and natNameFinder.cc.
    * Makefile.in: Regenerate.
    * prims.cc: Use trace_enabled from VMThrowable.
    * name-finder.cc: Removed.
    * gcj/javaprims.h: Add class VMThrowable.
    * gnu/gcj/runtime/NameFinder.java: New file.
    * gnu/gcj/runtime/natNameFinder.cc: Likewise.
    * include/name-finder.h: Removed.
    * java/lang/Throwable.java (printStackTrace (PrintStream)): Use new
    method stackTraceString().
    (printStackTrace (PrintWriter)): Likewise.
    (stackTraceString): Complete rewrite of old printStackTrace using
    (stackTraceStringBuffer): New helper method for stackTraceString().
    (fillInStackTrace): Delegate to VMTrowable.
    (getStackTrace): Likewise.
    (getStackTrace0): Removed.
    (trace_enabled, stackTraceBytes): Moved to new VMThrowable.java.
    (setStackTrace): Copy given array.
    * java/lang/natThrowable.cc: Removed (replaced by natVMThrowable).
    * java/lang/VMThrowable.java: New class.
    * java/lang/natVMThrowable.cc: New file.

Thanks for all your input.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: throwable.patch
Type: text/x-patch
Size: 51490 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20020824/75726cfc/attachment.bin>

More information about the Java-patches mailing list