Re: Throwable stack trace printing again

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Mon, 2002-07-29 at 19:02, Andrew Haley wrote:
>  > - 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.

I will follow the suggestion of Per Bothner and try to use
gnu.gcj.RawData for storage of the addresses and only convert them to
jlongs when needed later in NameFinder.

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

When everything else fails it will create a StackTraceElement with the
hexadecimal address (but you have to compile with
-Dgnu.gcj.runtime.remove_unknown=false to actually print them)
I hope that is good enough. I have never developed on embedded systems.

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

No, it can be moved to natVMThrowable.cc if that is more clear, I just

> Did you try it with addr2name.awk?

No since I thought that was only used on ia64 machines and it didn't
seem to work on my machine anyway. But now that I have actually looked
at the script I see that it didn't work because my awk is mawk and not
gawk which it seems to expect. My awk is also not in /bin/awk but in
/usr/bin/awk.

I will test it with my next patch since I see that I actually misspelled
the command name in my code and that it expects addresses to be "fully
zero filled" to work correctly.

> Without addr2line and c++filt?

Yes, it is easy to test by compiling with the different
-Dgnu.gcj.runtime.NameFinder properties set to true or false.
But I did find a bug when addr2line or c++filt is found but the
In/OutputStreams throw IOExceptions (I have a small patch to fix that).

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

It works fine with those, if the Stack is "sanatized" it even correctly
deduces the "real" top of the call stack when the exception occurs.

I will send a new patch later this week since I first want to get my
PowerPC machine working again so I can do some tests on a non-x86
platform... :{

Cheers,

Mark