Re: java.util.zip throws- oversubscribed dynamic bit lengths tree
Harsha Godugu wrote:
Dave Bristor wrote:
Hi Harsha,
Hi Dave,
Unfortunately there is no stand alone reproducible test case. It
appears that 6713913 and the issue I brought up here are related. Out
of curiosity, I was looking into inflater / deflater code to see what it
means to get the ' oversubscribed dynamic bit lengths tree'. According
to the code, it's due to the jar file being not in the right format when
the error occurred. The one thing that's suspicious here is, the jar
file creation. Their build uses maven's internal code to create a jar
file on the fly. (this problem happens consistently on Solaris & mac..
Is it possible to alter the build to use some other form of jar file creation?
Googling shows that there was a problem with zlib 1.1.2 that could cause the
particular "oversubscribed dynamic bit lengths tree" message, but that this
was fixed in zlib 1.1.3, which is what the JDK uses. Is it possible that
maven has its own implementation of zip code? I know that ant does; they rely
on some of the java.util.zip API but have their own code to read and write ZIP
files. I see that maven's sources include "maven-ant-tasks-2.0.8.jar". If
maven is using ant's ZIP code, perhaps the problem lies there. Could you check?
with that build.) If there is a jar file (format) verifier to examine
each bit of the (created) jar, then that would help nail down this
% zip
Copyright (C) 1990-1999 Info-ZIP
Type 'zip "-L"' for software license.
Zip 2.3 (November 29th 1999). Usage:
...
-T test zipfile integrity
% unzip
UnZip 5.52 of 28 February 2005, by Info-ZIP. Maintained by C. Spieler. Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.
Usage: unzip [-Z] [-opts[modifiers]] file[.zip] [list] [-x xlist] [-d exdir]
Default action is to extract files in list, except those in xlist, to exdir;
file[.zip] may be a wildcard. -Z => ZipInfo mode ("unzip -Z" for usage).
...
-t test compressed archive data
However, Sahoo provided a jar that caused a failure during build, and it
passes the above checks. So I don't know how thorough the above are.
Googling shows a few integrity checking tools, mostly for Windows.
problem. Would it also be a problem, if multiple threads accessing
As long as they're all reading, I believe it should not be a problem. If
there is a writer and N readers which are using the stream classes, and they
are properly synchronized, this should also work.
Thanks,
Dave
(reading ) the same jar? (Or any other jar related flags that could be
enabled to check the integrity of the jar would be of help here.)
I will add the stack traces to the same bug report.
thanks,
Harsha
One data point to not
Do you have a reproducible testcase? This appeared years before my
time, see 413, "java.util.zip.ZipException: oversubscribed dynamic
bit lengths tree", and was closed with the note "Irreproducible -
probably fixed some time ago."
Sahoo has filed 6713913, "Fatal errors during jar file processing",
but I'm unable to reproduce the problem.
Thanks,
Dave
thanks,
Harsha
Problem: When reading large jar files programatically, we get the
following exception.
Caused by: org.apache.maven.plugin.MojoExecutionException: Error
assembling JAR
at
com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:183)
at
com.sun.enterprise.module.maven.PackageMojo.execute(PackageMojo.java:193)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
... 16 more
Caused by: java.util.zip.ZipException: oversubscribed dynamic bit
lengths tree
at
java.util.zip.InflaterInputStream.read(InflaterInputStream.java:140)
at java.io.DataInputStream.readFully(DataInputStream.java:176)
at java.util.jar.JarFile.getBytes(JarFile.java:364)
at java.util.jar.JarFile.getManifestFromReference(JarFile.java:157)
at java.util.jar.JarFile.getManifest(JarFile.java:145)
at
com.sun.enterprise.module.common_impl.Jar$Archive.getManifest(Jar.java:172)
at
com.sun.enterprise.module.maven.Packager.configureManifest(Packager.java:126)
at
com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:168)
hg: jdk7/tl/jdk: 2 new changesets
Changeset: bc9a0bba6e72 Author:sherman Date: 2008-06-30 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc9a0bba6e72 6675856: Open charset tests Summary: Moved non-confidiential test cased from closed repo to open repo Reviewed-by: martin + test/sun/nio/cs/BufferUnderflowEUCTWTest.java + test/sun/nio/cs/CheckCaseInsensitiveEncAliases.java + test/sun/nio/cs/CheckHistoricalNames.java + test/sun/nio/cs/ConvertSingle.java + test/sun/nio/cs/Decode.java + test/sun/nio/cs/DecoderOverflow.java + test/sun/nio/cs/EUCJPUnderflowDecodeTest.java + test/sun/nio/cs/EucJpLinux0212.java + test/sun/nio/cs/EucJpLinuxDecoderRecoveryTest.java + test/sun/nio/cs/EuroConverter.java + test/sun/nio/cs/FindASCIICodingBugs.java + test/sun/nio/cs/FindASCIIRangeCodingBugs.java + test/sun/nio/cs/FindCanEncodeBugs.java + test/sun/nio/cs/FindDecoderBugs.java + test/sun/nio/cs/FindEncoderBugs.java + test/sun/nio/cs/FindOneCharEncoderBugs.java + test/sun/nio/cs/HWKatakanaMS932EncodeTest.java + test/sun/nio/cs/ISCIITest.java + test/sun/nio/cs/ISO2022JP.trailEsc + test/sun/nio/cs/ISO8859x.java + test/sun/nio/cs/JISAutoDetectTest.java + test/sun/nio/cs/LatinCharReplacementTWTest.java + test/sun/nio/cs/LeftOverSurrogate.java + test/sun/nio/cs/MalformedSurrogates.java + test/sun/nio/cs/NIOJISAutoDetectTest.java + test/sun/nio/cs/ReadZero.java + test/sun/nio/cs/SJISCanEncode.java + test/sun/nio/cs/StreamEncoderClose.java + test/sun/nio/cs/SurrogateGB18030Test.java + test/sun/nio/cs/SurrogateTestEUCTW.java + test/sun/nio/cs/SurrogateTestEUCTW.plane15.surrogates + test/sun/nio/cs/SurrogateTestEUCTW.plane3.surrogates + test/sun/nio/cs/SurrogateTestEUCTW.plane4.surrogates + test/sun/nio/cs/SurrogateTestEUCTW.plane5.surrogates + test/sun/nio/cs/SurrogateTestEUCTW.plane6.surrogates + test/sun/nio/cs/SurrogateTestEUCTW.plane7.surrogates + test/sun/nio/cs/SurrogateTestHKSCS.java + test/sun/nio/cs/Test4200310.sh + test/sun/nio/cs/Test4206507.java + test/sun/nio/cs/Test6254467.java + test/sun/nio/cs/Test6275027.java + test/sun/nio/cs/Test6392804.java + test/sun/nio/cs/TestCompoundTest.java + test/sun/nio/cs/TestConverterDroppedCharacters.java + test/sun/nio/cs/TestCp834_SBCS.java + test/sun/nio/cs/TestCp93xSISO.java + test/sun/nio/cs/TestIBMBugs.java + test/sun/nio/cs/TestISCII91.java + test/sun/nio/cs/TestISO2022CNDecoder.java + test/sun/nio/cs/TestISO2022JP.java + test/sun/nio/cs/TestISO2022JPEncoder.java + test/sun/nio/cs/TestISO2022JPSubBytes.java + test/sun/nio/cs/TestIllegalISO2022Esc.java + test/sun/nio/cs/TestIllegalSJIS.java + test/sun/nio/cs/TestJIS0208Decoder.java + test/sun/nio/cs/TestJIS0212Decoder.java + test/sun/nio/cs/TestMS5022X.java + test/sun/nio/cs/TestMiscEUC_JP.java + test/sun/nio/cs/TestSJIS0213.java + test/sun/nio/cs/TestTrailingEscapesISO2022JP.java + test/sun/nio/cs/TestUTF8BOM.java + test/sun/nio/cs/TestUTF_16.java + test/sun/nio/cs/TestUTF_32.java + test/sun/nio/cs/TestUni2HKSCS.java + test/sun/nio/cs/TestX11JIS0201.java + test/sun/nio/cs/UkrainianIsNotRussian.java + test/sun/nio/cs/ZeroedByteArrayEUCTWTest.java Changeset: 92b0c40af537 Author:sherman Date: 2008-06-30 14:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/92b0c40af537 Merge
Re: java.util.zip throws- oversubscribed dynamic bit lengths tree
Hi Harsha, Do you have a reproducible testcase? This appeared years before my time, see 413, "java.util.zip.ZipException: oversubscribed dynamic bit lengths tree", and was closed with the note "Irreproducible - probably fixed some time ago." Sahoo has filed 6713913, "Fatal errors during jar file processing", but I'm unable to reproduce the problem. Thanks, Dave Harsha Godugu wrote: Joseph D. Darcy wrote: Any idea who can help me with this exception.. If there isn't anything sensitive in your inquiry, you could send email to [EMAIL PROTECTED] Thanks Joe. Could anybody help me why we get into the following issue on/off. This (exception) happens when we try to read a large file during the build (of Glassfish v3). This problem is very difficult to reproduce and random in nature. (this is with both 1.5_xx and 1.6xx JDK). I will file bug against JDK after any insight here. thanks, Harsha -Joe thanks, Harsha Problem: When reading large jar files programatically, we get the following exception. Caused by: org.apache.maven.plugin.MojoExecutionException: Error assembling JAR at com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:183) at com.sun.enterprise.module.maven.PackageMojo.execute(PackageMojo.java:193) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: java.util.zip.ZipException: oversubscribed dynamic bit lengths tree at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:140) at java.io.DataInputStream.readFully(DataInputStream.java:176) at java.util.jar.JarFile.getBytes(JarFile.java:364) at java.util.jar.JarFile.getManifestFromReference(JarFile.java:157) at java.util.jar.JarFile.getManifest(JarFile.java:145) at com.sun.enterprise.module.common_impl.Jar$Archive.getManifest(Jar.java:172) at com.sun.enterprise.module.maven.Packager.configureManifest(Packager.java:126) at com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:168)
hg: jdk7/tl/jdk: 6 new changesets
Changeset: 2f21c9f8136a Author:mullan Date: 2008-06-17 10:34 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2f21c9f8136a 6673277: Thread unsafe lazy initialization code in sun.security.provider.certpath.*Checker classes Summary: make supportedExts variable non-static Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/ConstraintsChecker.java ! src/share/classes/sun/security/provider/certpath/KeyChecker.java ! src/share/classes/sun/security/provider/certpath/PolicyChecker.java Changeset: bc5159dc2a81 Author:mullan Date: 2008-06-17 10:53 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc5159dc2a81 Merge Changeset: 4be8dfa19e27 Author:mullan Date: 2008-06-19 14:20 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4be8dfa19e27 6714842: CertPathBuilder returns incorrect CertPath for BasicConstraints in builderParams Summary: Do not consider CA target certificates if selector.getBasicConstraints() == -2 Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java + test/java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java + test/java/security/cert/CertPathBuilder/targetConstraints/anchor.cer + test/java/security/cert/CertPathBuilder/targetConstraints/ca.cer + test/java/security/cert/CertPathBuilder/targetConstraints/ee.cer Changeset: 3a7345910333 Author:weijun Date: 2008-06-20 12:05 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3a7345910333 6716534: Krb5LoginModule has not cleaned temp info between authentication attempts Reviewed-by: valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java Changeset: 9cf5011bfe38 Author:wetmore Date: 2008-06-26 00:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9cf5011bfe38 Merge Changeset: 47c4a285e238 Author:wetmore Date: 2008-06-29 00:25 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/47c4a285e238 Merge
Re: Peculiar fruits in the JDK
Hi Sherman, I had a closer look to your code. Thanks for your hints. Looks interesting. Also I see some chances for optimization, but more exactly ...later. Can you tell me something about memory consuming in the current Sun JVM? How much bytes do byte arrays consume per byte? ... or in other words: is it less memory-consuming using byte arrays than int arrays, if these are large? Same question about short and char arrays? Thanks for a short answer. -Ulf Am 27.06.2008 18:52, Xueming Shen schrieb: Ulf, my apology for the belated response, I have been kept buzy in something else the last couple days and don't have time to dig into my "old" workspace to pick the files. Will do it next week or so... But in fact the first piece, or say the most import block, of my idea/plan has been already putback intot the JDK7 workspace with my fix for Japanese JIS0213 work. The JIS0213 charset is implemented by using the "new idea", instead of embedding the c2b/b2c mapping table into huge static String object into the class file, the impl generates a binary mapping data file from a text based b2c mapping file during the build-time, then initialize the b2c and c2bIndex/Table from this data file during its init-time... take a look at the newly added sun.nio.cs.CharsetMapping.java and the stuff under make/tool/Charsetmap... I'm in hurry, send you more later... sherman Ulf Zibis wrote: Hi Sherman, I am waiting for an answer from you. I myself only answered to the list http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-June/thread.html#511 Don't you read the list regularly? Regards, Ulf Am 24.06.2008 17:58, Xueming Shen schrieb: Ulf Zibis wrote: Btw, we are not going to do anything for the sun.io.XYZ classes, except removing them. I had once removed them from the J2SE but had to put them back for some reasons, but we are absolutely not going to do anything for that package. I've already eliminatred any use of that package in J2SE in JDK6. How did you eliminate the dependencies? E.g.: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/branches/milestone1/solaris/classes/sun/awt/motif/X11JIS0201.java?rev=201&view=markup I see, my work on sun.io was for the scrapheap. :-( If you have the source code for 5.x, you would find those X11 converters were sun.io based, I rewrote all of them in JDK6 and modified all the places in awt/font to use the java.nio.charset interface.. fortunately I was the original font/motif guy who wrote them in the first place, so not too difficult:-) I did the same thing for all sun.io.XYZConverter usages to use the java.nio.charset interface in J2SE workspace then actually removed the J2SE in JDK6 before beta, but had to put them back because BIG licensee insisted they have their JDBC bridge drivers still using sun.io and don't want to migrate. Yes, don't try to improve anything in sun.io package, our currently policy is to keep it there but don't do anything. That said, in order to rewrite the sun.nio.cs/ext package we might have to touch this package again, one of the ideas is to write a adaptor class to bridge the sun.io.Converter to sun.nio.cs implementation, so we can eliminate all those CharToByte/ByteToChar implementation, I have a draft implementation in one of my ws, but have not fully tested, will dig it out later. very much thank for appreciating my work, Really appreciate your work. The charset implementation work currently is not my priority simply because I lost my main codereviewer Martin (though he is still interested in this area after moving on to Google, I'm not so sure how much he can continue spend on this), so it would be easy to work on my other interesting areas. But seems like we now have a contributor who is very experienced and interested in charset:-) we should give it a try. I will send you some classes I was working on to share my thoughts/ideas later. But I would "warn" you that all the changes might not make into JDK7, there are sill some debates internally that whether or not we should spend our resource (very limited) on something that works (don't break it if it works:-)) Sherman
Re: java.util.zip throws- oversubscribed dynamic bit lengths tree
Joseph D. Darcy wrote: Any idea who can help me with this exception.. If there isn't anything sensitive in your inquiry, you could send email to [EMAIL PROTECTED] Thanks Joe. Could anybody help me why we get into the following issue on/off. This (exception) happens when we try to read a large file during the build (of Glassfish v3). This problem is very difficult to reproduce and random in nature. (this is with both 1.5_xx and 1.6xx JDK). I will file bug against JDK after any insight here. thanks, Harsha -Joe thanks, Harsha Problem: When reading large jar files programatically, we get the following exception. Caused by: org.apache.maven.plugin.MojoExecutionException: Error assembling JAR at com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:183) at com.sun.enterprise.module.maven.PackageMojo.execute(PackageMojo.java:193) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: java.util.zip.ZipException: oversubscribed dynamic bit lengths tree at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:140) at java.io.DataInputStream.readFully(DataInputStream.java:176) at java.util.jar.JarFile.getBytes(JarFile.java:364) at java.util.jar.JarFile.getManifestFromReference(JarFile.java:157) at java.util.jar.JarFile.getManifest(JarFile.java:145) at com.sun.enterprise.module.common_impl.Jar$Archive.getManifest(Jar.java:172) at com.sun.enterprise.module.maven.Packager.configureManifest(Packager.java:126) at com.sun.enterprise.module.maven.PackageMojo.createArchive(PackageMojo.java:168)
