From mail at alexkasko.com  Mon Jul 20 18:20:31 2015
From: mail at alexkasko.com (Alex Kashchenko)
Date: Mon, 20 Jul 2015 21:20:31 +0300
Subject: build for four target
In-Reply-To: <1835261857.3357361.1437393619732.JavaMail.root@ausy-group.com>
References: <1835261857.3357361.1437393619732.JavaMail.root@ausy-group.com>
Message-ID: <55AD3BEF.3030801@alexkasko.com>

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 ?

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

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

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.

>
> Cordially
>
> Antoine N.
>


-- 
-Alex

From mail at alexkasko.com  Tue Jul 28 16:59:26 2015
From: mail at alexkasko.com (Alex Kashchenko)
Date: Tue, 28 Jul 2015 19:59:26 +0300
Subject: build for four target
In-Reply-To: <2139302084.134807.1437483967705.JavaMail.root@ausy-group.com>
References: <2139302084.134807.1437483967705.JavaMail.root@ausy-group.com>
Message-ID: <55B7B4EE.6080502@alexkasko.com>

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

From omajid at redhat.com  Tue Jul 28 17:15:17 2015
From: omajid at redhat.com (Omair Majid)
Date: Tue, 28 Jul 2015 13:15:17 -0400
Subject: build for four target
In-Reply-To: <55AD3BEF.3030801@alexkasko.com>
References: <1835261857.3357361.1437393619732.JavaMail.root@ausy-group.com>
	<55AD3BEF.3030801@alexkasko.com>
Message-ID: <20150728171517.GD4064@redhat.com>

Hi,

* Alex Kashchenko <mail at alexkasko.com> [2015-07-20 14:21]:
> On 07/20/2015 03:00 PM, Antoine NIVOL wrote:
> >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.

Are you overwriting a zip file that's open for reading by any chance?
Have you tried setting the system property
'sun.zip.disableMemoryMapping'?

Thanks,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681

From anivol at ausy-group.com  Thu Jul 30 12:16:26 2015
From: anivol at ausy-group.com (Antoine NIVOL)
Date: Thu, 30 Jul 2015 14:16:26 +0200 (CEST)
Subject: build for four target
In-Reply-To: <55B7B4EE.6080502@alexkasko.com>
Message-ID: <839270818.1041527.1438258586260.JavaMail.root@ausy-group.com>

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

From mail at alexkasko.com  Thu Jul 30 13:56:12 2015
From: mail at alexkasko.com (Alex Kashchenko)
Date: Thu, 30 Jul 2015 16:56:12 +0300
Subject: build for four target
In-Reply-To: <839270818.1041527.1438258586260.JavaMail.root@ausy-group.com>
References: <839270818.1041527.1438258586260.JavaMail.root@ausy-group.com>
Message-ID: <55BA2CFC.70002@alexkasko.com>

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

From gnu.andrew at redhat.com  Thu Jul 30 20:54:05 2015
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 30 Jul 2015 16:54:05 -0400 (EDT)
Subject: [PATCH] b36 Release and retro-active security patch review
In-Reply-To: <1095342646.1482182.1438289333595.JavaMail.zimbra@redhat.com>
Message-ID: <898729835.1482837.1438289645453.JavaMail.zimbra@redhat.com>

We have a new release of IcedTea [0] and a new OpenJDK 6 release, b36
to go with it. This is made from the current state of the OpenJDK 6
repositories plus backports of the new security fixes included in 7u85
& 8u51.

The tarballs are available here:

https://java.net/projects/openjdk6/downloads/download/openjdk-6-src-b36-22_jul_2015.tar.gz
https://java.net/projects/openjdk6/downloads/download/openjdk-6-src-b36-22_jul_2015.tar.xz
 
SHA256 checksums:
 
9616b2365734ad34b0837dc99ba604513f9a12b602aadfdf334e46f9d59dac55  openjdk-6-src-b36-22_jul_2015.tar.gz
c9df23d208b3b61f5f57c030accca2f7b3218a97bd140668506265ececdf26f4  openjdk-6-src-b36-22_jul_2015.tar.xz

Changes since b36 (including both CPU fixes and upstreamed changes):

* Security fixes
  - S8043202, CVE-2015-2808: Prohibit RC4 cipher suites
  - S8067694, CVE-2015-2625: Improved certification checking
  - S8071715, CVE-2015-4760: Tune font layout engine
  - S8071731: Better scaling for C1
  - S8072490: Better font morphing redux
  - S8072887: Better font handling improvements
  - S8073334: Improved font substitutions
  - S8073773: Presume path preparedness
  - S8073894: Getting to the root of certificate chains
  - S8074330: Set font anchors more solidly
  - S8074335: Substitute for substitution formats
  - S8074865, CVE-2015-2601: General crypto resilience changes
  - S8074871: Adjust device table handling
  - S8075374, CVE-2015-4748: Responding to OCSP responses
  - S8075378, CVE-2015-4749: JNDI DnsClient Exception Handling
  - S8075738: Better multi-JVM sharing
  - S8075838: Method for typing MethodTypes
  - S8075853, CVE-2015-2621: Proxy for MBean proxies
  - S8076328, CVE-2015-4000: Enforce key exchange constraints
  - S8076376, CVE-2015-2628: Enhance IIOP operations
  - S8076397, CVE-2015-4731: Better MBean connections
  - S8076401, CVE-2015-2590: Serialize OIS data
  - S8076405, CVE-2015-4732: Improve serial serialization
  - S8076409, CVE-2015-4733: Reinforce RMI framework
  - S8077520, CVE-2015-2632: Morph tables into improved form
  - PR2488, CVE-2015-4000: Make jdk8 mode the default for jdk.tls.ephemeralDHKeySize
* Other changes
  - OJ58: Allow OpenJDK to build on PaX-enabled kernels
  - OJ59: Only apply PaX-marking when needed by a running PaX kernel
  - OJ60, PR2484: Disable export ciphers by default
  - OJ61: Remove translation strings for ErrorMsg.JAXP_INVALID_ATTR_VALUE_ERR which doesn't exist in OpenJDK 6
  - OJ62, PR2552: Restrict key size of RSA certificates to >= 1024
  - OJ63: Remove @Override annotation on interfaces added by 2015/07/14 security fixes.
  - S6787645: CRL validation code should permit some clock skew when checking validity of CRLs
  - S6996365: Evaluate the priorities of cipher suites
  - S7185471: Avoid key expansion when AES cipher is re-init w/ the same key
  - S8007142: Add utility classes for writing better multiprocess tests in jtreg
  - S8008089: Delete OS dependent check in JdkFinder.getExecutable()
  - S8024861: Incomplete token triggers GSS-API NullPointerException
  - S8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector
  - S8036786: Update jdk7 testlibrary to match jdk8
  - S8042205: javax/management/monitor/*: some tests didn't  get all the notifications
  - S8042982: Unexpected RuntimeExceptions being thrown by SSLEngine
  - S8043200, PR2485: Decrease the preference mode of RC4 in the enabled cipher suite list
  - S8043201: Deprecate RC4 in SunJSSE provider
  - S8046817: JDK 8 schemagen tool does not generate xsd files for enum types
  - S8048194: GSSContext.acceptSecContext fails when a supported mech is not initiator preferred
  - S8050158: Introduce system property to maintain RC4 preference order
  - S8062923: XSL: Run-time internal error in 'substring()'
  - S8062924: XSL: wrong answer from substring() function
  - S8064546: CipherInputStream throws BadPaddingException if stream is not fully read
  - S8065764: javax/management/monitor/CounterMonitorTest.java hangs
  - S8066952: [TEST-BUG] javax/management/monitor/CounterMonitorTest.java hangs
  - S8073357: schema1.xsd has wrong content. Sequence of the enum values has been changed
  - S8073385: Bad error message on parsing illegal character in XML attribute
  - S8074098: 2D_Font/Bug8067699 test fails with SIGBUS crash on Solaris Sparc
  - S8074297: substring in XSLT returns wrong character if string contains supplementary chars
  - S8075575: com/sun/security/auth/login/ConfigFile/InconsistentError.java failed in certain env.
  - S8075576: com/sun/security/auth/module/KeyStoreLoginModule/OptionTest.java failed in certain env.
  - S8075667: (tz) Support tzdata2015b
  - S8076290: JCK test api/xsl/conf/string/string17 starts failing after JDK-8074297
  - S8077685: (tz) Support tzdata2015d
  - S8078348: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails with BindException
  - S8078439: SPNEGO auth fails if client proposes MS krb5 OID
  - S8078666, PR2327: JVM fastdebug build compiled with GCC 5 asserts with "widen increases"
  - S8080318: jdk8u51 l10n resource file translation update
  - S8081386: Test sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh test has RC4 dependencies
  - S8081775: two lib/testlibrary tests are failing with "Error. failed to clean up files after test" with jtreg 4.1 b12

Webrevs for the new changes:
 
http://cr.openjdk.java.net/~andrew/openjdk6/20150714/root/
http://cr.openjdk.java.net/~andrew/openjdk6/20150714/corba/
http://cr.openjdk.java.net/~andrew/openjdk6/20150714/jaxp/
http://cr.openjdk.java.net/~andrew/openjdk6/20150714/jaxws/
http://cr.openjdk.java.net/~andrew/openjdk6/20150714/hotspot/
http://cr.openjdk.java.net/~andrew/openjdk6/20150714/jdk/
http://cr.openjdk.java.net/~andrew/openjdk6/20150714/langtools/

Once approved, I'll push these to the OpenJDK 6 repository.

[0] http://bitly.com/it11308

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


From gnu.andrew at redhat.com  Thu Jul 30 21:02:41 2015
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 30 Jul 2015 17:02:41 -0400 (EDT)
Subject: [PATCH] b36 Release and retro-active security patch review
In-Reply-To: <898729835.1482837.1438289645453.JavaMail.zimbra@redhat.com>
References: <898729835.1482837.1438289645453.JavaMail.zimbra@redhat.com>
Message-ID: <754044886.1494764.1438290161141.JavaMail.zimbra@redhat.com>


----- Original Message -----
> We have a new release of IcedTea [0] and a new OpenJDK 6 release, b36
> to go with it. This is made from the current state of the OpenJDK 6
> repositories plus backports of the new security fixes included in 7u85
> & 8u51.
> 
> The tarballs are available here:
> 
> https://java.net/projects/openjdk6/downloads/download/openjdk-6-src-b36-22_jul_2015.tar.gz
> https://java.net/projects/openjdk6/downloads/download/openjdk-6-src-b36-22_jul_2015.tar.xz
>  
> SHA256 checksums:
>  
> 9616b2365734ad34b0837dc99ba604513f9a12b602aadfdf334e46f9d59dac55
> openjdk-6-src-b36-22_jul_2015.tar.gz
> c9df23d208b3b61f5f57c030accca2f7b3218a97bd140668506265ececdf26f4
> openjdk-6-src-b36-22_jul_2015.tar.xz
> 
> Changes since b36 (including both CPU fixes and upstreamed changes):
> 
> * Security fixes
>   - S8043202, CVE-2015-2808: Prohibit RC4 cipher suites
>   - S8067694, CVE-2015-2625: Improved certification checking
>   - S8071715, CVE-2015-4760: Tune font layout engine
>   - S8071731: Better scaling for C1
>   - S8072490: Better font morphing redux
>   - S8072887: Better font handling improvements
>   - S8073334: Improved font substitutions
>   - S8073773: Presume path preparedness
>   - S8073894: Getting to the root of certificate chains
>   - S8074330: Set font anchors more solidly
>   - S8074335: Substitute for substitution formats
>   - S8074865, CVE-2015-2601: General crypto resilience changes
>   - S8074871: Adjust device table handling
>   - S8075374, CVE-2015-4748: Responding to OCSP responses
>   - S8075378, CVE-2015-4749: JNDI DnsClient Exception Handling
>   - S8075738: Better multi-JVM sharing
>   - S8075838: Method for typing MethodTypes
>   - S8075853, CVE-2015-2621: Proxy for MBean proxies
>   - S8076328, CVE-2015-4000: Enforce key exchange constraints
>   - S8076376, CVE-2015-2628: Enhance IIOP operations
>   - S8076397, CVE-2015-4731: Better MBean connections
>   - S8076401, CVE-2015-2590: Serialize OIS data
>   - S8076405, CVE-2015-4732: Improve serial serialization
>   - S8076409, CVE-2015-4733: Reinforce RMI framework
>   - S8077520, CVE-2015-2632: Morph tables into improved form
>   - PR2488, CVE-2015-4000: Make jdk8 mode the default for
>   jdk.tls.ephemeralDHKeySize

Copy and paste error; PR2488 is IcedTea-only as it depends on the backport
of S6956398, PR2486: make ephemeral DH key match the length of the certificate key.
b37 maybe?

OJ60 should be under security fixes really. It's a fix for the FREAK
issue; CVE-2015-0204: Disable export ciphers by default
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


From anivol at ausy-group.com  Fri Jul 31 09:07:13 2015
From: anivol at ausy-group.com (Antoine NIVOL)
Date: Fri, 31 Jul 2015 11:07:13 +0200 (CEST)
Subject: build for four target
In-Reply-To: <55BA2CFC.70002@alexkasko.com>
Message-ID: <657809054.1123831.1438333633544.JavaMail.root@ausy-group.com>

Hi Alex and Omair,
I try to fix the -Dsun.zip.DisableMemoryMapping to my VM argument but it doesn't works better.

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

From omajid at redhat.com  Fri Jul 31 23:12:58 2015
From: omajid at redhat.com (Omair Majid)
Date: Fri, 31 Jul 2015 19:12:58 -0400
Subject: [PATCH] b36 Release and retro-active security patch review
In-Reply-To: <898729835.1482837.1438289645453.JavaMail.zimbra@redhat.com>
References: <1095342646.1482182.1438289333595.JavaMail.zimbra@redhat.com>
	<898729835.1482837.1438289645453.JavaMail.zimbra@redhat.com>
Message-ID: <20150731231258.GC6151@redhat.com>

* Andrew Hughes <gnu.andrew at redhat.com> [2015-07-30 16:54]:
> Changes since b36 (including both CPU fixes and upstreamed changes):

I assume you meant b35 here.

>   - S8043200, PR2485: Decrease the preference mode of RC4 in the enabled cipher suite list

I don't quite follow this patch. If PRESERVE_RC4 is true, doesn't it put
SSL_RSA_WITH_RC4_128_MD5 at the top of the cipher list from its original
lower position?

That said, given that 8043202 removes these RC4 ciphers, it probably
doesn't matter.

>   - S8062923: XSL: Run-time internal error in 'substring()'
>   - S8062924: XSL: wrong answer from substring() function

This patch has a 'ORACLE PROPRIETARY/CONFIDENTIAL' header.

Looks okay to me otherwise.

Cheers,
Omair

-- 
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681