[kaffe] Playing with slots.h and "Internal error"

[Dalibor Topic]

On Sat, 2006-07-15 at 21:46 +0100, S K wrote:
> I was playing around with the slots codes and tried to add a new members to the _slots struct to
> change it to
> 
> typedef struct _slots {
>         union {
>                 jint            tint;
>                 jword           tword;
>                 jlong           tlong;
>                 jfloat          tfloat;
>                 jdouble         tdouble;
>                 void*           taddr;
>                 char*           tstr;
>         } v;
>         jword abcd;
> } slots;
> 
> Even though the JVM code compiles, when I try to run a simple java code, I get an internal error:
> 
> 
> Internal error: caught an unexpected exception.
> Please check your CLASSPATH and your installation.
> java/lang/ExceptionInInitializerError
>    at java.util.HashSet.<init> (HashSet.java:138)
>    at java.security.CodeSource.<init> (CodeSource.java:97)
> Internal error: caught an unexpected exception.
> Please check your CLASSPATH and your installation.
> java/lang/NullPointerException
>    at java.util.HashSet.<init> (HashSet.java:138)
>    at java.security.CodeSource.<init> (CodeSource.java:97)
> Aborted
> 
> Could anyone kindly explain why I am getting this and what I should be doing to correct this?

The easiest way to figure out why something is going wrong is to use a
debugger. Using gdb (See FAQ.debugging) and bt we see the following
backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210403136 (LWP 24303)]
0xb7d68a38 in java_lang_VMSystem_arraycopy0 (src=0x81bfc7c,
srcpos=12648430, dst=0xc0ffee, dstpos=136076024, len=12648430)
    at ../../../../kaffe/libraries/clib/native/System.c:104
104             dclass = OBJECT_CLASS(dst);
(gdb) bt
#0  0xb7d68a38 in java_lang_VMSystem_arraycopy0 (src=0x81bfc7c,
srcpos=12648430, dst=0xc0ffee, dstpos=136076024,
    len=12648430)
at ../../../../kaffe/libraries/clib/native/System.c:104


dst is off, since it is now 0xc0ffee (used internally in the interpreter
in debug mode to denote an uninitialized cell), and that's why it
crashes.

Why is dst off? loking at the backtrace we see:

#1  0xb7f77230 in engine_callMethod (call=0xbf9dcbe0) at
sysdepCallMethod.h:46
#2  0xb7f59f90 in KaffeVM_callMethodA (meth=0x817f068, func=0x817f068,
obj=0xc0ffee, args=0xbf9dcfac, ret=0xbf9de1d0,
    promoted=1) at ../../../kaffe/kaffe/kaffevm/javacall.c:275
#3  0xb7f76e75 in virtualMachine (meth=0x817f068, arg=0xbf9dcfac,
retval=0xbf9de1d0, thread_data=0x8096028)
    at ../../../../kaffe/kaffe/kaffevm/intrp/machine.c:190
#4  0xb7f6588b in runVirtualMachine (meth=0x817f00c, lcl=0xbf9dcf40,
sp=0xbf9dcfa0, npc=<value optimized out>,
    retval=0xbf9de1d0, mjbuf=0xbf9dd024, thread_data=0x8096028) at
kaffe.def:3135
#

java_lang_VMSystem_arraycopy0 is a native method. That means the VM has
to call it using the C conventions for argument passing, and needs to
assemble a call stack to do so. The native bits are in
sysdepCallMethod.h, but they don't have to bother you. The problem is
that the argument stack passed on to the native method does not actually
look like the argument stack it expects, due to legitimate stack value
being intermixed with the additional jword you added, so that the call
gets garbage in some of its arguments.

Fixing that means looking at how the callMethodInfo is assembled in
engine_callMethod in intrp and into KaffeVM_callMethodA. For example,
one could copy the callMethodInfo arguments into a fresh argument array,
and drop the jword of data in the process.

The implementation is left as an exercise for the reader. ;)

cheers,
dalibor topic