United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6305157 multiple Java threads are using JNI C++ method concurrently, access violations thrown. regression?
6305157 : multiple Java threads are using JNI C++ method concurrently, access violations thrown. regression?

Details
Type:
Bug
Submit Date:
2005-08-02
Status:
Resolved
Updated Date:
2012-11-02
Project Name:
JDK
Resolved Date:
2005-11-01
Component:
hotspot
OS:
windows_xp
Sub-Component:
runtime
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0u4
Fixed Versions:
5.0u6

Related Reports
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
This appears to be some form of regression from 1.5.0_02 to 1.5.0_04

When multiple Java threads are using JNI C++ method concurrently, access violations are thrown in the whole Java virtual machine of JDK 1.5.0_04. The same application worked fine without any problems on JDK 1.5.0_02

1) The problem can be reproduced on a 3.4Ghz Hyper Threading machine running Microsoft Windows XP SP2. The full system information is attached as file "sysinfo.zip". 
 
Swiching off the hyper threading features of the machine does not solve the issue. The problem can be reproduced with and without hyper theading enabled. 
 
2) Start the debugger (Microsoft Visual Studio .NET 2003), and configure it to "Break into the debugger" on access violations. (Debug > Exceptions > Win32 Exceptions -> Access Violation -> set the 2 "Break into the debugger" flags)  
 
3) Start the reproducer: java -cp . HelloWorld with the Java 1.5.0_04-b05 version mentioned above. The reproducer will first sleep for 20 seconds to allow attaching with the debugger. After the 20 seconds, it will load the "libHelloWorld.dll" and start 10 threads that will call the processInCpp native C++ method. The implementation of the processInCpp takes the byte array passed as argument and returns it. No additional processing is done. The reproducing code (sources and build) are in the reproducer.zip
in attachment.  
 
4) While the reproducer is sleeping, attach the debugger to the java.exe process.  
 
5) Wait for a few seconds until the first access violation is thrown and ignored by the java process.

Test case is in /net/cores.central/cores/64670658/reproducer
and it is also attached.

                                    

Comments
EVALUATION

see 6341455. This bug not applicable to 6 and above.
                                     
2010-08-04
EVALUATION

Since the fault is Windows only, a temporary relief is setting UseMembar default to true on Windows platform. Customer don't need to set vm options through cmd line, applet panel and environmental variables. A long term solution will be addressed by bug 6341455.
                                     
2005-10-25



Hardware and Software, Engineered to Work Together