build for four target

Thu Jul 30 12:16:26 UTC 2015

Hi jdk6-dev community,

The patch give by Alex Kashchenko doesn't solve my problem, so it's possible that my problem doesn't come from zip librairies.

I think it's a fail from my JRE build. 
For exemple, I have copy the msvcr100.dll to my jre/bin/ repertory to execute my software. 
On my last fonctionnal build, I don't have this librairie on this repertory.

So I'm build with the Visual Studio 2010 compliler
Compiler version: 16.0.40219.1
cygwin version 1.7.7
My architecture is a Intel core I7 with 64 bits Windows Seven SP1 OS
I'm trying to build the jdk 1.6.35 and my error comes when I execute my software on a intel atom.

For three other processor (intel i5, intel i7 or intel Centrino 2) the execution is fonctionnal.

I suspect the compiler's version and msvcr100.dll so I'm try to build with the visual studio 2003

Cordialy

thanks Alex for your patch.

Antoine NIVOL

----- Mail original -----
De: "Alex Kashchenko" <mail at alexkasko.com>
À: "Antoine NIVOL" <anivol at ausy-group.com>
Cc: "Sébastien RAMIREZ" <sramirez at ausy.fr>, "jdk6-dev" <jdk6-dev at openjdk.java.net>
Envoyé: Mardi 28 Juillet 2015 18:59:26
Objet: Re: build for four target

Hi Antoine,

On 07/21/2015 04:06 PM, Antoine NIVOL wrote:
> HI. Thanks for your answer.
>
> ----- Mail original -----
> De: "Alex Kashchenko" <mail at alexkasko.com>
> À: "Antoine NIVOL" <anivol at ausy-group.com>
> Cc: build-dev at openjdk.java.net, "Sébastien RAMIREZ" <sramirez at ausy.fr>, "jdk6-dev" <jdk6-dev at 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