SafeFetch leads to hard crash on macOS 14.4

[Maxim Kartashev]

Thank you!

Then it seems like only some regions are so protected. Perhaps, those that
macOS adds by itself to guard against buffer overruns and such?..

On Wed, Mar 13, 2024 at 2:44 AM Vitaly Provodin <
vitaly.provodin at jetbrains.com> wrote:

> Hi Stefan, Maxim,
>
> With the patch the version string is successfully printed - VM was not
> killed.
>
> 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://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/20240313/86f4ccf5/attachment-0001.htm>