Re: Updated throwable and stacktrace printing patch

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

Mark Wielaard writes:
 >
 > I wrote the code assuming that we want our stacktraces to look just like
 > conventional VM stacktraces and I believe this patch does that very
 > nicely. But maybe I have to think outside the box to see what you are
 > proposing here. (My box does not really include C or C++, as you have
 > seen, my main programming experience is with logic/functional languages
 > and some java.)

That's to assume that the "conventional" VM stack trace is, in some
way, ideal.  However, I don't accept that it is ideal in our
environment where we link to CNI and JNI code and sometimes interact
with other languages and system interfaces.

My approach to libgcj has been that we should try to do better than
conventional VMs when we can.  I believe that an informative stack
trace is one such opportunity.

 > When designing this piece of code I assumed that the user/programmer is
 > interested in the stacktrace produced by the code they wrote. And that
 > the programmer is not interested in how precisely the runtime
 > environment generates the exception, only in where the exception
 > occurred in the program they wrote.

Yes, I have no doubt that this is one perfectly valid way of looking
at how people might use gcj.  However, it's not the only way.

Some programmers may not be interested in gory details, but others
are.  For us to presume that a heavily obfuscated stack trace is an
appropriate default is IMO unjustified.

I don't disagree with much that you have done, because some
simplification of the stack trace was needed.  But in my opinion the
simplification that you present here is too great, and many
programmers who are trying to understand complex interactions with the
operating system in large real-world applications will not be helped
by a "don't worry, be happy" approach to diagnostic output.

For example, consider the case where a signal has been delivered to
some CNI code.  Do you want to know that and the location where it
happened in the stack trace displayed on the operator's console?  You
betcha.

And of course a user could set the appopriate property to reveal the
information they need.  But firstly, setting this property is fairly
obscure and secondly it is too late after the stack trace has been
printed; the information has gone.

[ And yes, I know that people can sometimes use gdb.  But this is not
always true, especially on long-running server processes. ]

 > The same is true for the way the runtime starts the actual entry
 > point of the program (void main(String[] args)). That is why the
 > sanitize routine explicitly removes all that "uninteresting" stuff
 > from the top and the bottom of the stacktrace.

But the runtime doesn't necessarily start that way.

 > This of course assumes that the runtime is behaving normally as it
 > should according to the VM specification.

Sure, and that's why we need a useful stack trace for bug reports.

 > What do you mean exactly when you say that you want to decode the signal
 > handler info?

At the moment we don't display the routine in which the null pointer
fetch occurs.  We display the routine that called it instead.

 > Is the fact that the null pointer or arithmetic exception was
 > internally processed by a signal handler really interesting to the
 > programmer? It seems like a runtime detail. Maybe you can send a
 > small piece of example code and tell how you think the stacktrace
 > should be printed?
 > 
 > > You could just print <signal>.
 > 
 > That is actually what happens now since I forgot about removing the
 > catch_segv/fpe() methods from the trace. But we can keep those if you
 > like. But first we have to find out why they don't show up when
 > compiling against shared libs.

It's probably because the return address is beyond the end of the
routine.  I don't think there's much we should do about that case.

 > > 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?
 > 
 > Are you talking about the equal test in Throwable.printStackTrace()?
 > That test is there for the case were you chain an exception inside a new
 > exception and then rethrow it.

Ah, OK.

Ultimately the choice of display format has to be based on a rational
cost-benefit analysis:

What is the cost of simplifying the stack trace?

What is the benefit of doing so?

Andrew.