Bug 232008

Summary:	Unable to use pack200 on JDT fragments
Product:	[Eclipse Project] JDT	Reporter:	Thomas Hallgren <thomas>
Component:	Core	Assignee:	Olivier Thomann <Olivier_Thomann>
Status:	VERIFIED NOT_ECLIPSE	QA Contact:
Severity:	normal
Priority:	P3	CC:	aniefer, jarthana, jerome_lanneluc, Olivier_Thomann, srikanth_sankaran
Version:	3.4
Target Milestone:	3.6 M1
Hardware:	PC
OS:	Linux
Whiteboard:

Description Thomas Hallgren

2008-05-14 02:11:12 EDT

We have a product in which we redistribute the headless parts of the jdt. This product is using pack200 internally for all features and bundles. At present, we cannot build the product unless we exclude these two fragments from the pack phase:

org.eclipse.jdt.compiler.apt_1.0.100.v20080414-2145.jar
org.eclipse.jdt.compiler.tool_1.0.100.v_858.jar

Stacktraces printed by the eclipse.jarProcessor ant-task during the pack phase:

Exception in thread "Main Thread" java.lang.SecurityException: SHA1 digest error for org/eclipse/jdt/internal/compiler/apt/dispatch/AnnotationDiscoveryVisitor.class
	at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:194)
	at java.util.jar.JarVerifier.processEntry(JarVerifier.java:201)
	at java.util.jar.JarVerifier.update(JarVerifier.java:188)
	at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:411)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
	at java.io.FilterInputStream.read(FilterInputStream.java:66)
	at com.sun.java.util.jar.pack.ClassReader$1.read(ClassReader.java:43)
	at java.io.DataInputStream.readInt(DataInputStream.java:370)
	at com.sun.java.util.jar.pack.ClassReader.readMagicNumbers(ClassReader.java:139)
	at com.sun.java.util.jar.pack.ClassReader.read(ClassReader.java:122)
	at com.sun.java.util.jar.pack.PackerImpl$DoPack.readClass(PackerImpl.java:490)
	at com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:464)
	at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:73)
	at com.sun.java.util.jar.pack.Driver.main(Driver.java:261)
Exception in thread "Main Thread" java.lang.SecurityException: SHA1 digest error for org/eclipse/jdt/internal/compiler/tool/Archive.class
	at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:194)
	at java.util.jar.JarVerifier.processEntry(JarVerifier.java:201)
	at java.util.jar.JarVerifier.update(JarVerifier.java:188)
	at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:411)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
	at java.io.FilterInputStream.read(FilterInputStream.java:66)
	at com.sun.java.util.jar.pack.ClassReader$1.read(ClassReader.java:43)
	at java.io.DataInputStream.readInt(DataInputStream.java:370)
	at com.sun.java.util.jar.pack.ClassReader.readMagicNumbers(ClassReader.java:139)
	at com.sun.java.util.jar.pack.ClassReader.read(ClassReader.java:122)
	at com.sun.java.util.jar.pack.PackerImpl$DoPack.readClass(PackerImpl.java:490)
	at com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:464)
	at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:73)
	at com.sun.java.util.jar.pack.Driver.main(Driver.java:261)

Comment 1 Jerome Lanneluc

2008-05-15 05:00:36 EDT

Would you have more information on the reason why pack200 flags these .class files as having a problem? I.e. why is pack200 throwing this SecurityException?

Comment 2 Thomas Hallgren

2008-05-15 05:24:33 EDT

(In reply to comment #1)
> Would you have more information on the reason why pack200 flags these .class
> files as having a problem? I.e. why is pack200 throwing this SecurityException?
> 
No, not much. I get the error when I include them in a zip and pass that zip to the eclipse.jarProcessor ant task with the pack="true" jar="<the zip>". No other options are given. The zip contains a lot of other jars, both from the platform and from our application. None of them pose any problems. Just these two.

The zip passes through a 'normalize' without erros prior to the pack attempt but during that phase I guess nothing should happen to these fragments since their eclipse.inf marks them as processed already.

Comment 3 Jerome Lanneluc

2008-05-15 06:39:09 EDT

Olivier, does this ring any bell?

Comment 4 Olivier Thomann

2008-05-15 08:59:41 EDT

These two jars are the only ones compiled using a compliance 1.6. So maybe this is a bug in pack200 that cannot handle stack map attributes.

Comment 5 Andrew Niefer

2008-05-21 12:25:44 EDT

> The zip passes through a 'normalize' without erros prior to the pack attempt
> but during that phase I guess nothing should happen to these fragments since
> their eclipse.inf marks them as processed already.

I think the jar may be getting re-normalized.  Normally this should not be an issue.  See however bug 226850, fixed in M7.  The SDK conditions/packs all of its jars using effort level 4 because we have seen some .class file corruption in the past using the default level 5.  This bug 226850 could potentially cause the jars to be reconditioned using a different effort level, which may cause problems.

Try updating the org.eclipse.update.core bundle in your builder to get the fix.

As well, you could try lowering the effort level to 4 for all your bundles.  Do this by placing a pack.properties file in the root of the zip with a property 
"pack200.default.args=-E4"

Comment 6 Olivier Thomann

2009-06-26 11:05:25 EDT

Thomas,

Did Andrew hint fix your issue ?

Comment 7 Thomas Hallgren

2009-06-26 11:21:11 EDT

No, lowering the effort didn't help so we removed the pack of those jars. I suspect that it might be related to another issue with Pack200 not working correctly with J9 version 6. See bug 279596.

Comment 8 Olivier Thomann

2009-06-26 11:25:12 EDT

There is nothing we can do from our side.
Closing as NOT_ECLIPSE ?

Comment 9 Olivier Thomann

2009-07-21 16:02:39 EDT

Closing as NOT_ECLIPSE.

Comment 10 Jay Arthanareeswaran

2009-08-04 06:10:44 EDT

Verified for 3.6M1