build for four target

Mon Aug 10 17:50:03 UTC 2015

Hi Antoine,

On 07/31/2015 12:07 PM, Antoine NIVOL wrote:
> Hi Alex and Omair,
> I try to fix the -Dsun.zip.DisableMemoryMapping to my VM argument but it doesn't works better.

Yes, this flag is not implemented in jdk6.

Could you please try with the updated version of the patch - 
http://cr.openjdk.java.net/~akasko/jdk6/windows_amd64_zip_2/webrev/

It includes the previous patch (so should be applied to the clean tree), 
also it includes the flag Omair mentioned (hardcoded to not use mmap 
here, line 93  - 
http://cr.openjdk.java.net/~akasko/jdk6/windows_amd64_zip_2/webrev/src/share/classes/java/util/zip/ZipFile.java.html 
). It also passes all the jdk zip tests on win-amd64.

>
> I also try to make a piece of code for reproduce the bug like on my software but I think it is many cause for one problem.
>
> I don't make some trickery with my jar file, it's in native or basic call of the jdk what cause my VM crash.
>
> Antoine
>
> ----- Mail original -----
> De: "Alex Kashchenko" <mail at alexkasko.com>
> À: "Antoine NIVOL" <anivol at ausy-group.com>
> Cc: "jdk6-dev" <jdk6-dev at openjdk.java.net>
> Envoyé: Jeudi 30 Juillet 2015 15:56:12
> Objet: Re: build for four target
>
> 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