JDK-6342951 : Implicit null checks on large objects cause JVM crash
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: x86
  • Submitted: 2005-10-27
  • Updated: 2012-10-08
  • Resolved: 2005-11-30
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 JDK 6
5.0u7Fixed 6 b62Fixed
Description
The attached test case shows a bug in null check handling in HotSpot. The original problem was reported by the LWJGL team in the following two threads:

http://lwjgl.org/forum/viewtopic.php?t=1287
http://www.javagaming.org/forums/index.php?topic=11255.0

The test case, which should throw a NullPointerException, crashes the JVM on Solaris/x86 as far back as 1.4.0 and on Windows as far back as 1.5.0, though it doesn't seem to appear on SPARC platforms (with this test case, although a crash could probably be provoked with a larger object). The problem is that HotSpot is generating implicit null checks for a field dereference in a large object and the field offset is larger than the page size. HotSpot's signal handler only treats faults on the zero page as implicit null checks and changes in the explicit null check mechanism on various platforms (specifically, removal of explicit null check support in some places) have opened up this possibility of a crash. The interpreter and both compilers appear to be vulnerable to this problem.
Comments
EVALUATION Yes, this bug fix is being backported to 5.0 update 7 (as I type).
05-12-2005
EVALUATION Fixed 6342951: Implicit null checks on large objects cause JVM crash The interpreter was missing some null_check calls in the putfield/getfield cases, which determines whether a null check should be explicitly generated against the object, otherwise the field access will generate the null check. In both cases, the SEGV signal causes the NullPointerException to be thrown. The VM assumes that it can elide null checks if the offset of the object access is less than a page because the signal handler treats segv's on the first page to be NPE. This doesn't work for field accesses in the interpreter since the offset dynamic. The interpreter has to generate a null check against the object itself and not rely on the field access to segv on the first page instead. I ran specJVM -Xint and there was no performance difference with the additional null checks for field accesses, that should have been there anyway. So we don't suffer performance decrease for correctness of an unusual case. C2 already had not elided null check if the offset is greater than page size, as needs_explicit_null_check() tests. Tom gave me the c1 fix to do the same thing, included in this webrev. Fix verified (y/n): y Verified by : Test nsk/regression/b6342951 added to NSK Other testing: specjvm x86 -Xint and runThese -jck -client/-server sparc Webrev: http://jruntime.east/~coleenp/webrev/6342951 Reviewed by: phh, kbr
15-11-2005
EVALUATION The interpreter was missing some null_check calls in the putfield/getfield cases, which determines whether a null check should be explicitly generated against the object, otherwise the field access will generate the null check. In both cases, the SEGV signal causes the NullPointerException to be thrown. The VM assumes that it can elide null checks if the offset of the object access is less than a page because the signal handler treats segv's on the first page to be NPE. This doesn't work for field accesses in the interpreter since the offset dynamic. The interpreter has to generate a null check against the object itself and not rely on the field access to segv on the first page instead. I fixed all the platform code in the interpreters to do this. I don't know how bad the performance will be, or if there's anything we can do about it. Unless there's a max java object size we can use in needs_explicit_null_check() that isn't 2**64. The compilers are still broken, although I can't get C2 to compile the code in the test program without putting uncommon_traps in. C1 crashes on my test case though. The compilers can probably tell the field offset and not elide the null check by using the needs_explicit_nul_check() call.
09-11-2005