[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [kaffe] Re: Bug Status of Kaffe



Hi Mark, hi all,

Mark Wielaard wrote:
Hi,

On Thu, 2003-12-25 at 03:12, Ben Burton wrote:

#210716 jython causes kaffe to fail with assert error

       ,----
       | Version: 1:1.1.1-1
       |
       | > After removing the JNI lines from jython shell script (see
       | > issue #207998) kaffe dies with kaffe-bin: machine.c:620:
       | > installMethodCode: Assertion `e->start_pc <= e->end_pc'
       | > failed.

[...]
But this crash is not a debian-specific bug.  The bug here is that jython
causes kaffe to crash on startup *after* all of the required classes have
been found - it has nothing to do with the library path.
[..]
This is where this crash comes up.  Once you have kaffe finding all of the
JNI libraries that it should (including the ones used with jython and the
kaffe bootstrap classes), it then crashes with 'e->start_pc <= e->end_pc'
failed.

So this is definitely a kaffe issue, not a debian-specific issue or a JNI
path issue.


Seen the same crash when using the CVS view from Eclipse 3.0M4 on kaffe.
<http://kaffe.org/pipermail/kaffe/2003-October/044318.html>
I just removed the assert.

The problem is actually the byte code generated by the compiler since it
should not generate an exception table entry whose start_pc is smaller
(or equal - the assert is actually wrong) to end_pc.

So basically, jython has been compiled by a buggy compiler ;) The JVM Spec 2nd Edition says in $4.7.3 'The Code Attribute' :
[snip]

exception_table[]
Each entry in the exception_table array describes one exception handler in the code array. The order of the handlers in the exception_table array is significant. See Section 3.10 for more details.

    Each exception_table entry contains the following four items:

    start_pc, end_pc
The values of the two items start_pc and end_pc indicate the ranges in the code array at which the exception handler is active. The value of start_pc must be a valid index into the code array of the opcode of an instruction. The value of end_pc either must be a valid index into the code array of the opcode of an instruction or must be equal to code_length, the length of the code array. The value of start_pc must be less than the value of end_pc.

[snip]

See http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html for an online version.

I think the proper way to fix that bug is to recompile jython with another java compiler.

The attached patch turns the assert into a printf WARNING which can help
debug the byte code. In my eclipse case it says:
WARNING start_pc=164661273 end_pc=164661236 in
org/eclipse/team/internal/core/streams/TimeoutInputStream.runThread(()V)
WARNING start_pc=164661775 end_pc=164661236 in
org/eclipse/team/internal/core/streams/TimeoutInputStream.runThread(()V)
WARNING start_pc=161990681 end_pc=161990644 in
org/eclipse/team/internal/core/streams/TimeoutOutputStream.runThread(()V)
WARNING start_pc=161991183 end_pc=161990644 in
org/eclipse/team/internal/core/streams/TimeoutOutputStream.runThread(()V)


I'll check it into kaffe's CVS as the current assert is not very user friendly. I'll change the warning message, though, to

WARNING Bad bytecode! Illegal exception table: start_pc=sth not lower than end_pc=sth in method something_else().
See Java Virtual Machine Specification 2nd Edition $4.7.3 for details.
Please report this bug to the developers of the application you're running on kaffe. A simple fix might be to use another java compiler.

cheers,
dalibor topic



Reply to: