JDK-6305157 : multiple Java threads are using JNI C++ method concurrently, access violations thrown. regression?
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0u4
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-08-02
  • Updated: 2013-06-21
  • Resolved: 2005-11-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0u6 b04Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
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