|
Quick Lists
|
|
Bug ID:
|
6444959
|
|
Votes
|
0
|
|
Synopsis
|
NullPointerException without user code in stack trace when running under N1 Grid Engine 6.0u8
|
|
Category
|
hotspot:runtime_system
|
|
Reported Against
|
|
|
Release Fixed
|
|
|
State
|
11-Closed, duplicate of 6374692,
bug
|
|
Priority:
|
3-Medium
|
|
Related Bugs
|
6374692
,
6478739
|
|
Submit Date
|
29-JUN-2006
|
|
Description
|
The following exception happens when running some VM tests under N1 Grid Engine. It only happens sometimes. There is no obvious pattern. It is also not very easy to reproduce as it requires running tests under Tonga harness. Let me know what can be done to track the source of the problem.
Exception in thread "main" java.lang.NullPointerException
at java.security.Permissions.add(Permissions.java:117)
at java.net.URLClassLoader.getPermissions(URLClassLoader.java:495)
at sun.misc.Launcher$AppClassLoader.getPermissions(Launcher.java:284)
at java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:192)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
Posted Date : 2006-06-29 10:29:57.0
|
|
Work Around
|
The VM option -XX:-ImplicitNullChecks is a workaround for non-product VMs.
|
|
Evaluation
|
This bug appears to be a variant of 6374692. The stack extends all the way down to the first page, so null pointers do not cause a SEGV, and implicit null checks generated by C2 do not work properly.
One possible solution is to employ the workaround proposed for 6374692 so that the VM can prevent stack growth from making virtual address 0 valid.
Posted Date : 2006-07-19 15:10:32.0
This bug is a duplicate of 6374692, after applying the IDR123656-01 (assuming 118855-15+)
the issue is fixed.
Here is a pmap of the process after applying the patch.
+ pmap 100667
+ ./jre1.6.0/bin/java -server -Xcomp Main 1000
100667: ./jre1.6.0/bin/java -server -Xcomp Main 1000
100667: ./jre1.6.0/bin/java -server -Xcomp Main 1000
08045000 12K rwx-- [ stack ]
08050000 44K r-x-- /var/tmp/ksrini/jre1.6.0/bin/java
0806A000 4K rwx-- /var/tmp/ksrini/jre1.6.0/bin/java
0806B000 16K rwx-- [ heap ]
Posted Date : 2006-07-27 21:20:04.0
This is really a duplicate of 6374692, and will be closed as such, solved by the aforementioned patch, a defensive mechanism should be implemented in the VM addressed
by 6478739.
Posted Date : 2006-10-05 19:09:32.0
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |