JDK-8006807 : C2 crash due to out of bounds array access in Parse::do_multianewarray
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-01-23
  • Updated: 2014-10-15
  • Resolved: 2013-02-07
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.
JDK 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
Related Reports
Relates :  
Description
Please review the fix for the following issue and create a BugID/Submit the change if you find it appropriate:

http://cr.openjdk.java.net/~simonis/webrevs/do_multianewarray/

The change for "7058510:multinewarray with 6 dimensions uncommon traps in server compiler" replaced the fixed sized, stack allocated array 'length' of length 5 with a dynamically, arena allocated array of size 'ndimensions + 1':

  Node** length = NEW_RESOURCE_ARRAY(Node*, ndimensions + 1);
  length[ndimensions] = NULL;  // terminating null for make_runtime_call

In cases where 'ndimensions' is smaller than 4 (and bigger than 1 because the 1-dimensional case is handled specially) this leads to field accesses beyond the bounds of the 'length' array later on during the call to 'make_runtime_call(..)' which can eventually crash the compiler:

    c = make_runtime_call(RC_NO_LEAF | RC_NO_IO,
                          OptoRuntime::multianewarray_Type(ndimensions),
                          fun, NULL, TypeRawPtr::BOTTOM,
                          makecon(TypeKlassPtr::make(array_klass)),
                          length[0], length[1], length[2],
                          length[3], length[4]);

Notice that these crashes are extremely rare, because usually, there is still some accessible memory beyond the arena allocated 'length' array. We only observed four crashes because of this problem in regular nightly runs of JVM2008 during the last six month. The crashes only happened on Windows although the problem is platform independent. I also couldn't reproduce the problem with a test program which ran for several hours and constantly compiled a method which allocated several two- and three-dimensional arrays so I refrained from writing a regression test for this problem.

The fix is trivial: just check the value of 'ndimensions' before accessing the corresponding 'length' slots and use NULL values for the cases where the array slots do not exist. Notice that we only call make_runtime_call if 'ndimensions' is bigger than 1 in which case 'length' already contains three entries (see allocation of the 'length' array above).

    c = make_runtime_call(RC_NO_LEAF | RC_NO_IO,
                          OptoRuntime::multianewarray_Type(ndimensions),
                          fun, NULL, TypeRawPtr::BOTTOM,
                          makecon(TypeKlassPtr::make(array_klass)),
                          length[0], length[1], length[2],
                          (ndimensions > 2) ? length[3] : NULL,
                          (ndimensions > 3) ? length[4] : NULL);

Thank you and best regards,
Volker

Comments
Justifying "no-regtest", I excerpt this bit from the description above: "Notice that these crashes are extremely rare, because usually, there is still some accessible memory beyond the arena allocated 'length' array. We only observed four crashes because of this problem in regular nightly runs of JVM2008 during the last six month. The crashes only happened on Windows although the problem is platform independent. I also couldn't reproduce the problem with a test program which ran for several hours and constantly compiled a method which allocated several two- and three-dimensional arrays so I refrained from writing a regression test for this problem."
06-02-2013