SafeFetch leads to hard crash on macOS 14.4

[Stefan Karlsson]

On 2024-03-14 09:49, Vitaly Provodin wrote:
> Stefan,
>
>>> With the patch the version string is successfully printed - VM was 
>>> not killed.
>>
>> Did you run this on 14.4? Did you also run this on an AArch64 machine?
>
> Both questions: Yes

OK. Thanks.

> I can recheck it again (if it is needed). There maybe something wrong 
> with my build...

I think we have enough information at this point, so I don't think you 
need to dig further into this. Thanks for helping out.

StefanK

>
> Vitaly
>
>
>> On 13. Mar 2024, at 13:27, Stefan Karlsson 
>> <stefan.karlsson at oracle.com> wrote:
>>
>> Hi Vitaly,
>>
>> On 2024-03-12 23:44, Vitaly Provodin wrote:
>>> Hi Stefan, Maxim,
>>>
>>> With the patch the version string is successfully printed - VM was 
>>> not killed.
>>
>> Did you run this on 14.4? Did you also run this on an AArch64 machine?
>>
>> FWIW, I updated a machine to 14.4 and could reproduce the reported 
>> problem with a patch similar to the one below. I also managed to 
>> write a stand-alone C reproducer, which I have added to the bug report.
>>
>> Thanks,
>> StefanK
>>
>>>
>>> Thanks,
>>> Vitaly
>>>
>>>
>>>> On 12. Mar 2024, at 17:19, Stefan Karlsson 
>>>> <stefan.karlsson at oracle.com> wrote:
>>>>
>>>> Hi again,
>>>>
>>>> I just want to clarify that the change above just removes *one* 
>>>> usage of SafeFetch. My guess is that all other usages of SafeFetch 
>>>> is still affected by the issue you are seeing.
>>>>
>>>> It would be interesting to see if you could verify this problem by 
>>>> applying this patch:
>>>>
>>>> diff --git a/src/hotspot/share/memory/universe.cpp 
>>>> b/src/hotspot/share/memory/universe.cpp
>>>> index 2a3d532725f..b58c52e415b 100644
>>>> --- a/src/hotspot/share/memory/universe.cpp
>>>> +++ b/src/hotspot/share/memory/universe.cpp
>>>> @@ -842,7 +842,14 @@ jint universe_init() {
>>>>    return JNI_OK;
>>>>  }
>>>>
>>>> +#include "runtime/safefetch.hpp"
>>>> +
>>>>  jint Universe::initialize_heap() {
>>>> +  char* mem = os::reserve_memory(16 * K, false, mtGC);
>>>> +  intptr_t value = SafeFetchN((intptr_t*)mem, 1);
>>>> +
>>>> +  log_info(gc)("Reserved memory read: " PTR_FORMAT " " PTR_FORMAT, 
>>>> p2i(mem), value);
>>>> +
>>>>    assert(_collectedHeap == nullptr, "Heap already created");
>>>>    _collectedHeap = GCConfig::arguments()->create_heap();
>>>>
>>>>
>>>> and running:
>>>> build/<config_path>/jdk/bin/java -version
>>>>
>>>> This works on 14.3.1, but it would be interesting to see what 
>>>> happens on 14.4, and if that shuts down the VM before it is 
>>>> printing the version string.
>>>>
>>>> StefanK
>>>>
>>>> On 2024-03-12 09:34, Stefan Karlsson wrote:
>>>>> Hi Maxim,
>>>>>
>>>>> On 2024-03-12 08:12, Maxim Kartashev wrote:
>>>>>> Hello!
>>>>>>
>>>>>> This has been recently filed as 
>>>>>> https://bugs.openjdk.org/browse/JDK-8327860 but I also wanted to 
>>>>>> check with the community if any further info on the issue is 
>>>>>> available.
>>>>>>
>>>>>> It looks like in some cases SafeFetch is directed to fetch 
>>>>>> something the OS really doesn't want it to and, instead of 
>>>>>> promoting the error to a signal and letting the application (JVM) 
>>>>>> deal with it, immediately terminates the application. All we've 
>>>>>> got is the OS crash report, not even the JVM's fatal error log. 
>>>>>> This looks like an application security precaution, which I am 
>>>>>> not at all familiar with.
>>>>>>
>>>>>> The relevant pieces of the crash log are below. Is anybody 
>>>>>> familiar with "Namespace GUARD" termination reason and maybe 
>>>>>> other related novelties of macOS 14.4? The error was not reported 
>>>>>> before upgrading to 14.4
>>>>> I don't have an answer for this, but a note below:
>>>>>
>>>>>> Thanks in advance,
>>>>>>
>>>>>> Maxim.
>>>>>>
>>>>>> 0 libjvm.dylib 0x1062d6ec0 _SafeFetchN_fault + 0
>>>>>> 1 libjvm.dylib 0x1062331a4 ObjectMonitor::TrySpin(JavaThread*) + 408
>>>>>> 2 libjvm.dylib 0x106232b44 ObjectMonitor::enter(JavaThread*) + 228
>>>>>> 3 libjvm.dylib 0x10637436c ObjectSynchronizer::enter(Handle, 
>>>>>> BasicLock*, JavaThread*) + 392
>>>>> FYI: I think that this specific call to SafeFetch was recently 
>>>>> removed by:
>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/29397d29baac3b29083b1b5d6b2cb06e456af0c3__;!!ACWV5N9M2RV99hQ!MxH9PbSoMKT5I4e02Kkz2Sk1O3hStNxJuKBvsvK5GLi_k_rusbuYduHFzMUqPmzB5FZgTBpgdghtEhMW2QRCYe45o9VfzGctxA$
>>>>> https://bugs.openjdk.org/browse/JDK-8320317
>>>>>
>>>>> Cheers,
>>>>> StefanK
>>>>>
>>>>>
>>>>>> ...
>>>>>>
>>>>>> Exception Type:        EXC_BAD_ACCESS (SIGKILL)
>>>>>> Exception Codes:       KERN_PROTECTION_FAILURE at 0x00000001004f4000
>>>>>> Exception Codes:       0x0000000000000002, 0x00000001004f4000
>>>>>>
>>>>>> Termination Reason:    Namespace GUARD, Code 5
>>>>>>
>>>>>> VM Region Info: 0x1004f4000 is in 0x1004f4000-0x1004f8000;  bytes 
>>>>>> after start: 0  bytes before end: 16383
>>>>>>       REGION TYPE                    START - END         [ VSIZE] 
>>>>>> PRT/MAX SHRMOD  REGION DETAIL
>>>>>>       mapped file                 1004e4000-1004f4000    [ 64K] 
>>>>>> r--/r-- SM=COW  Object_id=fa8d88e7
>>>>>> --->  VM_ALLOCATE                 1004f4000-1004f8000    [ 16K] 
>>>>>> ---/rwx SM=NUL
>>>>>>       VM_ALLOCATE                 1004f8000-1004fc000    [ 16K] 
>>>>>> r--/rwx SM=PRV
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20240314/ed25f105/attachment-0001.htm>