RFR: 8320308: C2 compilation crashes in LibraryCallKit::inline_unsafe_access
Vladimir Ivanov
vlivanov at openjdk.org
Wed Sep 4 17:26:23 UTC 2024
On Thu, 4 Jul 2024 12:17:51 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:
> We failed in `LibraryCallKit::inline_unsafe_access()` while trying to inline `Unsafe::getShortUnaligned`.
> https://github.com/openjdk/jdk/blob/34c6e0deac567c0f4ed08aa2824671551d843e95/test/hotspot/jtreg/compiler/parsing/TestUnsafeArrayAccessWithNullBase.java#L86
> The reason is that base (the array) is `ConP #null` hidden behind two `CheckCastPP` with `speculative=byte[int:>=0]`
>
> We call `Node* adr = make_unsafe_address(base, offset, type, kind == Relaxed);`
> https://github.com/openjdk/jdk/blob/34c6e0deac567c0f4ed08aa2824671551d843e95/src/hotspot/share/opto/library_call.cpp#L2361
> - with **base** = `147 CheckCastPP`
> - `118 ConP === 0 [[[ 106 101 71 ] #null`
> <img width="470" alt="type" src="https://github.com/user-attachments/assets/cbe5497e-cb0c-4f8e-a5d5-7a6ee1157778">
>
> Depending on the **offset** we go two different paths in `LibraryCallKit::make_unsafe_address` which both lead to the same error in the end.
> 1. For `UNSAFE.getShortUnaligned(array, 1_049_000)` we get kind = `Type::AnyPtr` because `offset >= os::vm_page_size()`. Since we assume base can't be null we insert an assert:
> https://github.com/openjdk/jdk/blob/34c6e0deac567c0f4ed08aa2824671551d843e95/src/hotspot/share/opto/library_call.cpp#L2111
>
> 2. whereas for `UNSAFE.getShortUnaligned(array, 1)` we get kind = `Type:: OopPtr`
> https://github.com/openjdk/jdk/blob/c17fa910cf3bad48547a3f0d68a30795ec3194e6/src/hotspot/share/opto/library_call.cpp#L2078
> and insert a null check
> https://github.com/openjdk/jdk/blob/34c6e0deac567c0f4ed08aa2824671551d843e95/src/hotspot/share/opto/library_call.cpp#L2090
> In both cases we return call `basic_plus_adr(..)` on a base being `top()` which returns **adr** = `1 Con === 0 [[ ]] #top`
>
> https://github.com/openjdk/jdk/blob/3d5d51e228c19aa216451f647023101ae8bdbc79/src/hotspot/share/opto/library_call.cpp#L2386 => `_gvn.type(adr)` is _top_
>
> https://github.com/openjdk/jdk/blob/3d5d51e228c19aa216451f647023101ae8bdbc79/src/hotspot/share/opto/library_call.cpp#L2394 => `adr_type` is _nullptr_
>
> https://github.com/openjdk/jdk/blob/3d5d51e228c19aa216451f647023101ae8bdbc79/src/hotspot/share/opto/library_call.cpp#L2405-L2406 => `BasicType bt` is _T_ILLEGAL_
>
> https://github.com/openjdk/jdk/blob/3d5d51e228c19aa216451f647023101ae8bdbc79/src/hotspot/share/opto/library_call.cpp#L2424 => we fail here with `SIGSEGV: null pointer dereference` because `alias_type->adr_type()` is _nullptr_
>
> ### Fix
> the fix is to bailed out in this case
> https://github.com/openjdk/jdk/blob/3d5d51e228c19a...
Thanks for the clarifications, Toby. I reconsidered my conclusion about root cause.
I agree that redundant `CheckCastPP` causes problems here, but what surprises me is that `null_check_oop` successfully detects that `base == NULL` while `LibraryCallKit::classify_unsafe_addr()` has a hard time doing the same. IMO the discrepancy is the source of the problem here. Can you share more details why it happens?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20033#issuecomment-2329610838
More information about the hotspot-compiler-dev
mailing list