There is a bug in Sun's java.util.jar.Manifest
that can lose the last header in the manifest if the file has a very particular
shape. We've hit this before in https://bugs.eclipse.org/bugs/show_bug.cgi?id=256787.
This could potentially be the source
of your problem.
Also, when we first started investigating
pack200 a few years ago, it seemed that the Pack200.packer implementation
had a memory leak. We always ran out of memory after processing some
number of bundles (10? 20? I forget).
The implementation used some statics
that were never cleared. This is why we went with execing pack200.exe
in a separate process. Have you not encountered these memory issues?
Thomas Hallgren <thomas@xxxxxxx> Sent by: p2-dev-bounces@xxxxxxxxxxx
05/09/2009 07:00 AM
Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>
The former obtains the Manifest from the JarInputStream.getManifest()
method and then writes it back. During that flow the parser/writer seems
to change a byte or two in the manifest itself. The consequence of using
this pack method is that the manifest digest is no longer valid in some
respects, which brings us to problem #2.
2. The default jarsigner at build.eclipse.org is and old 1.4.2 version.
Apparently it doesn't check the manifest digest. Hence my confusion that
the unpacked jars seemed valid.
3. The OSGi SignatureVerifier doesn't discover the invalid manifest when
using a IBM J9 Java 6. I haven't been able to pinpoint why that is. The
Java 5 version always fails and so does a Sun Java 6 on other machines.
The solution was to change Buckminsters jarpacker to use the other
Packer.pack() method. A bit unfortunate since it broke an otherwise
very efficient pipe scheme. But I can live with that :-)
Thanks for your help and support. I added some suggestions on how to
improve the way we handle pack200 on
p2-dev mailing list