kaffe 0.8.3, linux/i386, and a core dump

Erik Schnetter erik.schnetter at student.uni-tuebingen.de
Wed Apr 2 07:22:30 PST 1997


I am experiencing problems with the jit of kaffe 0.8.3 on linux-i386. 
It's Linux 2.0.27 (just for the record).  Depending on which program I run
under kaffe I get either an "IOT Trap" or a "Illegal instruction". 

I don't use native methods.  I don't use any graphics.  And I don't use
javac.  I use my own compiler... 

...and before you stand up and point to me, saying "Your fault!  Debug
your compiler instead!" I'd like to add that yes, the compiler is probably
not completely bug-free.  But 'java -verify' executes the program without 
a complaint.  And because the problem is an illegal instruction, and 
because I use kaffe as JIT compiler, might it not be possible that 
there's a problem within kaffe?

I have come to think of 'java -verify' as a pretty good standard to
compare against.  Up to now every error of 'java -verify' pointed me to a
bug in my compiler (a Sather compiler,
http://www.icsi.berkeley.edu/Sather).  The fact that there is no such
error message any more makes me confident that the produced code is
correct.  The additional fact that the output of the program, when run
under 'java', is what I expect, confirms this opinion. 

That leaves the Black Peter (German saying) with kaffe.  I took some
shallow dives into kaffe (0.7.1; there was a bug regarding the 'wide'
instruction) but this time it seems to be more serious.  The places where
the error occurs are at strange locations.  I don't get any debug
information.  Seems as if (whoops!) kaffe produced some code of its own
and fails executing it. 

I have, naturally, a pretty good impression of what is going on in my
compiler.  I also know a thing or two about the code that it produces (and
javap helps).  However, I am not familiar at all with the code generator
in kaffe, and therefore I thought it might be easier for you to isolate
the bug than for me. 

I have several small test programs which (unfortunately, in this case)
compile and run fine.  The error occurs in the compiler's test suite,
which is, of course, quite large.  So I propose that -- should someone be
interested -- I put the offending code (gtarzipped) into some ftp
location.  You're then free to have a look at it.

The code, when run with

	kaffe test > test-output

should execute a lot of compiler self tests.  Due to some problems in the
library not all tests succeed, but as the generated bytecode is legal (I
hope) kaffe should be able to execute it.  As said above, 'java 
-verify' does not complain.  Thank you in advance. 


PS: The ftp location is


(You need a file system that supports names up to 200 characters long. 
Sorry for this.)

PPS: I noticed that kaffe 0.8.3 cannot handle stack traces on class files
that don't have line number information.  This is unfortunate.  Shouldn't
it just omit the line numbers instead of swallowing the whole stack trace? 

A class file compiled by the Sather compiler conains source locations in
several different files.  The standard LineNumberAttribute does not
contain a source file name.  Is there a standard way to store such debug
information?  Does kaffe support such an attribute? 

Erik Schnetter, erik.schnetter at student.uni-tuebingen.de

More information about the kaffe mailing list