Hi Antoine,
On 07/21/2015 04:06 PM, Antoine NIVOL wrote:
HI. Thanks for your answer.
----- Mail original -----
De: "Alex Kashchenko" <m...@alexkasko.com>
À: "Antoine NIVOL" <ani...@ausy-group.com>
Cc: build-...@openjdk.java.net, "Sébastien RAMIREZ" <srami...@ausy.fr>, "jdk6-dev"
<jdk6-dev@openjdk.java.net>
Envoyé: Lundi 20 Juillet 2015 20:20:31
Objet: Re: build for four target
Hi Antoine,
On 07/20/2015 03:00 PM, Antoine NIVOL wrote:
Hi,
I'm using a build on four differents machines, they use the Windows 7 SP1 32
bits operating system.
the first one is a DELL (64 bits) with Intel core I7 for my devellopement and
the jdk build.
The second is a Panasonic with intel centrino Vpro for a product.
The third is a Panasonic with intel core I5 for a product.
And the last is a logic instrument fieldbook with a Intel Atom for a product.
I have build the version 1.6.35 with cygwin for this four machines.
Are you building sources from this repository -
http://hg.openjdk.java.net/jdk6 ?
Yes I use the repository : http://hg.openjdk.java.net/jdk6
The last logic instrument doesn't work after a few secondes (30 or 45) of
execution.
the error stack is below :
C [ntdll.dll+0x52d37] RtlFreeHeap+0xcd
C [ntdll.dll+0x52ce8] RtlFreeHeap+0x7e
C [kernel32.dll+0x4c484] HeapFree+0x14
C [msvcr100.dll+0x1016a] free+0x1c
C [zip.dll+0x7709] Java_java_util_zip_ZipEntry_initFields+0x58de
J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
V [jvm.dll+0x12453a]
V [jvm.dll+0x1d013e]
V [jvm.dll+0x1245bd]
V [jvm.dll+0xd89b4]
C [java.dll+0x1061]
Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2Ljava_security_AccessControlContext_2+0x17
J java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;
The error occur at several zone on my software but the top six lines are always
similar.
Does it happen only on particular hardware and works fine on other
machines? Do you have a code snippet (or an erroneous zip file) to
reproduce this? Or is it happened during the build, not during the
normal run?
Yes it happen only on logic instrument fieldbook with a Intel Atom. My software
works with the same build on three differents hardware.
And my software works with an other build (1.6.25) on Intel Atom.
I think the software was not the error cause, I point to my finger the jdk's
build and the librairies that I use.
The error occur on the normal run of my software.
I'm used a buid of Zip import from those sites :
http://gnuwin32.sourceforge.net/packages/bzip2.htm
http://gnuwin32.sourceforge.net/packages/unzip.htm
http://gnuwin32.sourceforge.net/packages/zip.htm
I will try to build with another version of zip and unzip.
This part is not clear. Do you mean zip and unzip utilities that are
used during the build? Then I can recommend to use native ones
(non-cygwin/msys/gnuwin) from info-zip.
This is mandatory's utils for the jdk's build.
There is a link between utility use for the jdk's build and the binary was used
in that stack error?
No, I think these utilities are used only during build-time and
unrelated to the actual problem.
I try to build the unzip and zip from info-zip but I'm not succed.
But the stacktrace above looks like that this is a problem with zip
implementation included with jdk6 sources -
http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/ca2c9f498b70/src/share/native/java/util/zip
Do you have any solution to my problem? Or just an idea?
I can try to reproduce this, I think there were similar issues with zlib
in jdk on erroneous zip files. And the in-tree zlib in jdk6 most
probably wasn't updated for a while as linux builds usually use platform
zlib instead of it.
PS: it looks like this question is specific to jdk6, so I am CC'ing
jdk6-dev. Please remove build-dev from copy if this is actually
jdk6-specific.
I looked into the zip details - jdk6 uses ancient 1.1.3 version of zlib [1].
It is not easy to update, as it is used in multiple modules [2][3][4]
and its implementation changed substantially in jdk7 [5][6][7].
I prepared the version with only
src/share/native/java/util/zip/zlib-1.1.3 updated to zlib-1.2.8 and with
src/share/native/java/util/zip and src/share/classes/java/util/zip
unchanged. Zlib-1.1.3 directory name is also unchanged to minimize
Makefile changes. It compiles on windows-amd64 and passes all the tests
in [8], but I am not sure that it will solve your problem as the
stacktrace points to internal jdk code in src/share/native/java/util/zip.
You can try the patch here:
- webrev:
http://cr.openjdk.java.net/~akasko/jdk6/windows_amd64_zip/webrev/
- patch itself:
http://cr.openjdk.java.net/~akasko/jdk6/windows_amd64_zip/webrev/jdk.patch
If it won't help - please let me know, I will try to backport some more
zip-related bits from jdk7. And if you'll get a "reproducer" code
snippet or particular zip file - it will help with investigation.
Also please note, that this patch is "unupstreamable" (due to zip
changes in jdk7), so you'll need to keep it internally for the following
jdk6 versions.
PS: for the following messages please subscribe for jdk6-dev mailing
list, currently your emails do not appear there.
[1]
http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/ca2c9f498b70/src/share/native/java/util/zip/zlib-1.1.3/ChangeLog#l4
[2]
http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/ca2c9f498b70/make/com/sun/java/pack/Makefile#l66
[3]
http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/ca2c9f498b70/make/java/jli/Makefile#l55
[4]
http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/ca2c9f498b70/make/sun/splashscreen/FILES_c.gmk#l52
[5] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/fc52d0a1fcda
[6] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/79760c3c4308
[7] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/e3790f3ce50a
[8]
http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/ca2c9f498b70/test/java/util/zip
Cordially
Antoine N.
--
-Alex
