[kaffe] Re: Bug Status of Kaffe

[Dalibor Topic]

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