Re: [platform-releng-dev] [eclipse-build]Build N20120118-2000 (Timestamp

[Satyam Kandula <satyam.kandula@xxxxxxxxxx>]

The ant test Frameworkests.testIncludeAntRuntime
is failing due to the verifyError. I couldn't reproduce
this error on my machine with Oracle Java 7 Update 2. 
Kim, do you see any other differences that could be possible
on the test machine. 

Thanks,
Satyam. 



From:      
 Srikanth S Adayapalam/India/IBM@IBMIN
To:      
 platform-releng-dev@xxxxxxxxxxx
Date:      
 01/20/2012 10:22 AM
Subject:    
   Re: [platform-releng-dev]
[eclipse-build]Build N20120118-2000 (Timestamp: 201201182000):Build is
complete. Test failures/errors occurred.
Sent by:    
   platform-releng-dev-bounces@xxxxxxxxxxx

---

> The build page from last night now reflects the results of running
the
tests on Windows with Java 7.

[...]

Kim

> The build just extracts the Oracle Java 7 update 2 for Windows and
runs
the tests. There isn't any special configuration.  Not sure what is
happening here.
>
> Kim

Hello Kim,

Here is a very likely explanation of what is going on:

Java SE 6 introduced a faster byte code verification algorithm based on
stack map frames
that is supposed to phase out the JDK5's classic verification algorithm.
In
order to allow
for a smooth transition, a Java SE 6 compliant compiler is required to
generate stack
map tables for this new verifier to work with, but if the JRE6's verifier
found some
problems with the class file, it is allowed to silently fall back to the
classic algorithm.

On the other hand, this fall back option has been tightened in JRE7/JDK7
time frame.
So a Java7 vm will upon encountering a class file with improper/invalid
stack map
information, MUST abort with a verify error and it is not allowed to fall
back silently.

You can however force even the JDK7 VM to fall back to the classic
verification
mode by using the VM argument -XX:-UseSplitVerifier.

So I think till date the JRE which was of vintage 6 has been silently
falling back
while JRE 7 to which you have upgraded recently, barks since it is mandated
to bark.

For JDT/Core, the crucial and urgent question is whether any of these
classes
with which the VM is unhappy  got compiled by ecj - which would indicate
a bug in our compiler. (We have at M4 and M5 fixed several bugs in this
space.)

Looking at a class name like:
com.sun.crypto.provider.PBEKeyFactory.engineGetKeySpec,
I am guessing we are not in the picture at all, (we are combing through
all
errors as I write this mail). If these classes which don't verify properly
were
not produced by us, then (a) we need to upgrade these libraries to a more
recent version (b) or use the fall back mode mentioned above for now.

We are continuing to study these failures.

Thanks!
Srikanth


_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-releng-dev