build for four target

Thu Jul 30 13:56:12 UTC 2015

Hi Antoine,

On 07/30/2015 03:16 PM, Antoine NIVOL wrote:
> 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.

According to stacktrace it comes from 
jdk/src/share/native/java/util/zip/ZipEntry.c that is a layer between 
java code and zlib library.

This part was changed in jdk7. Also without the reproducer it's hard to 
investigate the problem directly, so I am going to backport some more 
bits from jdk7 and update the patch (probably during the following week).

>
> 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.

I saw this msvcr100.dll problem before (with 6b31 I think), but never 
investigated it, I don't have this problem anymore with 6b35. It is most 
probably unrelated to zip crash.

>
> 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.

Could you please check the consistency of JAR files (ones bundled with 
the jdk and external ones too) on that machine? Also are you doing any 
trickery with JAR files during the program run - copying them somewhere 
or rewriting? There were fixes related to such operations in jdk7. It 
also was asked in this email 
(http://mail.openjdk.java.net/pipermail/jdk6-dev/2015-July/003525.html) 
but I'm afraid the suggestion from it won't help with jdk6, I think 
"sun.zip.disableMemoryMapping" wasn't backported to jdk6.

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

It won't work, only VS2010 (or Win SDK 7.1 that is almost the same) will 
work with jdk6/7/8.

>
> 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