SafeFetch leads to hard crash on macOS 14.4

[Maxim Kartashev]

> 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.

For whatever reason, it only crashed in ObjectMonitor::TrySpin(). Perhaps,
it's just the first one that is reached.

Anyway, I'll check the patch and get back to you.

On Tue, Mar 12, 2024 at 2:18 PM 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://github.com/openjdk/jdk/commit/29397d29baac3b29083b1b5d6b2cb06e456af0c3
> >
> > 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/20240312/4e9065c6/attachment.htm>