RFR(XS): Compiler crash due to out of bounds array access in Parse::do_multianewarray

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Jan 23 15:35:35 PST 2013


Thank you, Volker

I created 8006807 for this.

Thanks,
Vladimir

On 1/21/13 10:40 AM, Volker Simonis wrote:
> 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/
> <http://cr.openjdk.java.net/%7Esimonis/webrevs/do_multianewarray/>
>
> The change<http://cr.openjdk.java.net/%7Eiveresov/7058510/webrev.03/>
> for "7058510:multinewarray with 6 dimensions uncommon traps in server
> compiler <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7058510>"
> 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


More information about the hotspot-compiler-dev mailing list