[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Galileo mirroring problem. [SOLUTION]

If I remember correctly, in addition to being just "pure" memory leak, this problem would also cause the packing to not be stable (for example pack A, would depend on what would have been packed before)/
Do you remember something similar Andrew, Jeff, or it just me?

Inactive hide details for Andrew Niefer---05/11/2009 09:45:43 AM---Thomas,Andrew Niefer---05/11/2009 09:45:43 AM---Thomas,


From:

Andrew Niefer/Ottawa/IBM@IBMCA

To:

P2 developer discussions <p2-dev@xxxxxxxxxxx>

Date:

05/11/2009 09:45 AM

Subject:

Re: [p2-dev] Galileo mirroring problem. [SOLUTION]





Thomas,
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?

-Andrew


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>
To
P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc
Subject
Re: [p2-dev] Galileo mirroring problem. [SOLUTION]




The problem was threefold:
1. Buckminster uses its own Pack200 implementation and the Java
Pack200.Packer has two methods:

pack(JarInputStream input, OutputStream out);
pack(JarFile input, OutputStream out);

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
https://bugs.eclipse.org/bugs/show_bug.cgi?id=275533

Regards,
Thomas Hallgren
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


GIF image

GIF image