Bug 159654 - [compiler] unverifiable bytecode created by current cvs head compiler
Summary: [compiler] unverifiable bytecode created by current cvs head compiler
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.2.2   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 159822 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-10-03 17:49 EDT by Tom Tromey CLA
Modified: 2007-01-16 02:10 EST (History)
4 users (show)

See Also:


Attachments
.class file, output of ecj (10.18 KB, application/octet-stream)
2006-10-03 17:49 EDT, Tom Tromey CLA
no flags Details
Proposed fix (2.28 KB, patch)
2006-10-04 10:36 EDT, Olivier Thomann CLA
no flags Details | Diff
Regression test (1.20 KB, patch)
2006-10-04 10:44 EDT, Olivier Thomann CLA
no flags Details | Diff
Proposed patch (2.61 KB, patch)
2006-10-04 11:00 EDT, Philipe Mulet CLA
no flags Details | Diff
New patch (2.57 KB, patch)
2006-10-04 11:50 EDT, Olivier Thomann CLA
no flags Details | Diff
New regression tests (1.66 KB, patch)
2006-10-04 11:50 EDT, Olivier Thomann CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Tromey CLA 2006-10-03 17:49:07 EDT
I'm using the current cvs head compiler to compile GNU Classpath.
This compiler generates invalid bytecode for a particular file.
I tried but I was unable to reduce the test case to something smaller.

I'll attach the .class file.  I'm happy to send a pointer to the source
file as well, but I've been told before that you couldn't look at
GPL (or even GPL+exception I suppose) sources...

Here's the error messages from our bytecode verifier:

../../../../../trunk/libjava/classpath/java/text/RuleBasedCollator.java:312: error: verification failed at PC=239: stack sizes differ
../../../../../trunk/libjava/classpath/java/text/RuleBasedCollator.java:312: error: verification failed at PC=239: stack sizes differ
../../../../../trunk/libjava/classpath/java/text/RuleBasedCollator.java:312: error: verification failed at PC=239: unmergeable type

I think the bug is that the result from the invokevirtual at
PC=204 is not popped.
Comment 1 Tom Tromey CLA 2006-10-03 17:49:48 EDT
Created attachment 51382 [details]
.class file, output of ecj
Comment 2 Olivier Thomann CLA 2006-10-03 18:34:26 EDT
I'll investigate.
Thanks Tom for the test case.
Comment 3 Olivier Thomann CLA 2006-10-03 18:49:59 EDT
Tom,

Would you have a test case to show the error?
What version of the GNU Classpath are you trying to compile?

Thanks.
Comment 4 Olivier Thomann CLA 2006-10-03 19:01:13 EDT
I could successfully create an instance of your .class file type using reflect.
So I definitely need a reproducable test case to track it down.
Comment 5 Tom Tromey CLA 2006-10-03 19:03:16 EDT
Sorry, I don't have a reduced test case.
I tried to reduce the classpath code but wasn't able to make it fail :(

I'm trying to compile the version of classpath on gcj's "gcj-eclipse" branch:

http://gcc.gnu.org/viewcvs/branches/gcj-eclipse/libjava/

The particular file in question is:

http://gcc.gnu.org/viewcvs/branches/gcj-eclipse/libjava/classpath/java/text/RuleBasedCollator.java?revision=114362&view=markup
Comment 6 Tom Tromey CLA 2006-10-03 19:14:36 EDT
Hmm... could the code be loading built-in RuleBasedCollator from
your bootclasspath?

Or do you think the bytecode in question is ok?  I can attach
a disassembly if that would help.

By my reading the value pushed at PC=207 is never popped.  This means
that the branch from PC=185 to PC=239 "arrives" with an empty stack,
but the fall-through case from PC=238 "arrives" with a 1-element stack --
and this violates a JVM constraint.
Comment 7 Olivier Thomann CLA 2006-10-03 19:24:59 EDT
(In reply to comment #6)
> Hmm... could the code be loading built-in RuleBasedCollator from
> your bootclasspath?
I used -Xbootclasspath/p: to add the current folder in which I had your version of the .class file.

> Or do you think the bytecode in question is ok?  I can attach
> a disassembly if that would help.
No, thanks. I can disassemble it using our own disassembler.
 
> By my reading the value pushed at PC=207 is never popped.  This means
> that the branch from PC=185 to PC=239 "arrives" with an empty stack,
> but the fall-through case from PC=238 "arrives" with a 1-element stack --
> and this violates a JVM constraint.
Indeed. i'll try to reproduce it.

What should I used to retrieve the code? cvs or svn?
Comment 8 Olivier Thomann CLA 2006-10-03 22:25:01 EDT
This problem might be due to the optimization of unused locals. I'll dig more tomorrow, but on your side, try to recompile with -preserveAllLocals on the command line. It might work.
Set severity to critical.
Comment 9 Philipe Mulet CLA 2006-10-04 07:39:22 EDT
>This problem might be due to the optimization of unused locals.
Feels like it is a different problem than bug 159021. The offending optimization wasn't producing non verifiable code. Just some <clinit> invocation side-effect were lost.
Comment 10 Olivier Thomann CLA 2006-10-04 10:03:20 EDT
I also believe that this is a different issue than bug 159021. However my experiment yesterday makes me believe that it is related to the optimization of unused locals.
I am trying to isolate the issue.
Comment 11 Olivier Thomann CLA 2006-10-04 10:36:01 EDT
Created attachment 51407 [details]
Proposed fix
Comment 12 Olivier Thomann CLA 2006-10-04 10:44:38 EDT
Created attachment 51408 [details]
Regression test
Comment 13 Tom Tromey CLA 2006-10-04 10:54:26 EDT
Thanks for persevering with this.
I'll try the proposed patch today.
Comment 14 Philipe Mulet CLA 2006-10-04 11:00:42 EDT
Created attachment 51409 [details]
Proposed patch

I would rather write it like this. Same end effect though.
Comment 15 Olivier Thomann CLA 2006-10-04 11:10:55 EDT
What version do you want to release?
Comment 16 Olivier Thomann CLA 2006-10-04 11:19:49 EDT
Tom, please wait that the fix is validated.
Comment 17 Olivier Thomann CLA 2006-10-04 11:50:32 EDT
Created attachment 51412 [details]
New patch

Based on Philippe's patch
Comment 18 Olivier Thomann CLA 2006-10-04 11:50:51 EDT
Created attachment 51413 [details]
New regression tests
Comment 19 Olivier Thomann CLA 2006-10-04 13:55:33 EDT
Released for 3.3M3.
Regression test added in org.eclipse.jdt.core.tests.compiler.regression.CastTest#test042/043.
Comment 20 Tom Tromey CLA 2006-10-04 17:27:29 EDT
I updated and rebuilt, and the bug is now gone.
Thanks for fixing this so quickly!
Comment 21 Olivier Thomann CLA 2006-10-04 22:38:12 EDT
*** Bug 159822 has been marked as a duplicate of this bug. ***
Comment 22 Philipe Mulet CLA 2006-10-05 11:39:19 EDT
+1 for 3.2.2
reopening
Comment 23 Olivier Thomann CLA 2006-10-05 11:50:59 EDT
Tagged as 3.2.2
Comment 24 Olivier Thomann CLA 2006-10-11 11:42:02 EDT
Released for 3.2.2.
Added regression tests org.eclipse.jdt.core.tests.compiler.regression.CastTest#test041/42
Comment 25 David Audel CLA 2006-10-30 07:03:01 EST
Verified for 3.3 M3 using build I20061030-0010
Comment 26 Maxime Daniel CLA 2007-01-16 02:10:30 EST
Verified for 3.2.2 using build M20070112-1200.