SIGSEGV in AlignedHeapSegment::segmentIndexFromStart

[dulinriley]

Bug Description

Sometimes when Hermes is used in React Native apps, it might experience a segfault when
trying to encode a compressed pointer.

The specific stack trace is shown here:

hermes::vm::AlignedHeapSegment::segmentIndexFromStart(void const*)
hermes/include/hermes/VM/AlignedHeapSegment.h:530:48

hermes::vm::BasedPointer::computeSegmentAndOffset(void const*)
hermes/include/hermes/VM/PointerBase-inline.h:49:0

hermes::vm::BasedPointer::BasedPointer(void*)
hermes/include/hermes/VM/PointerBase-inline.h:35:0
...
hermes::vm::SlotAcceptorDefault::accept(hermes::vm::BasedPointer&)
hermes/include/hermes/VM/SlotAcceptorDefault-inline.h:29:0
...
hermes::vm::AlignedHeapSegment::updateReferences(hermes::vm::GenGC*, hermes::vm::FullMSCUpdateAcceptor*, hermes::ConsumableRange<std::__ndk1::__wrap_iter<hermes::vm::VTable const* const*> >&)
hermes/lib/VM/gcs/AlignedHeapSegment.cpp:355:0

• I have run gradle clean and confirmed this bug does not occur with JSC
  This bug is a crash in Hermes's GC, therefore it cannot happen with JSC.

Hermes version: v0.5.x (but likely exists in v0.7.0 as well)
Platform: Compressed pointers only exist on arm64-v8a

Steps to Reproduce

I haven't found a reliable way to reproduce the issue with a test app. Original reports came from
specific users.

[dulinriley]

This encoding happens during AlignedHeapSegment::updateReferences during a full Garbage Collection
cycle. The update references phase is changing pointers to point to the new location in memory before
compaction occurs.

This is a bit odd, because these pointers are constructed by the GC, from previously existing compressed pointers.
There are two possibilities here:

• There's a bug in forwarding a pointer to its compacted location, yielding an invalid pointer that can't be compressed
• Marking something that is not an object, such that it thinks something is a compressed pointer, when it isn't. Various bad dereferencing will occur, but might not crash immediately without ASAN on

The former seems more likely, but we haven't seen anything from our tests.

[dulinriley]

Note that we have seen a similar problem occur rarely in some FB internal apps, except it happens
in OldGen::markYoungGenPointers. In that case, it is actually a bad VTable, which results in decoding
a compressed pointer that is actually not a pointer at all. I'm not sure yet if the underlying root cause is
the same here, as they're in two different GC paths.

[raghav-mylagary]

@dulinriley We are running into this crash on the latest React Native-0.63.4 with the Hermes-0.5.1 engine. 40% of our user base is getting this crash after we upgraded to the latest React Native.

We couldn't reproduce this crash on both JSC and V8 engine. So this crash is definitely related to the Hermes engine.
I attached the tombstone file and crash dump after running through the ndk-stack tool as mentioned here https://github.com/facebook/hermes/blob/master/doc/ReactNativeIntegration.md#reporting-native-crashes

tombstone.txt

Crash dump.txt

[dulinriley]

Hi @raghavyadavm thanks for reporting this. I'm surprised that this error is occurring so often for your app. This is a tricky bug that will require a lot of work in a debugger like gdb to figure out what's going wrong.

Are you able to reproduce this issue consistently on your own device, using a debug build of your app? If so, is it possible that you could isolate the smallest amount of JS source code that causes the issue and put it in an open-source repo that I could clone and debug?

[JerakRus]

Hello! We all have numerous failures, it is difficult to figure out whether they are connected without a trace stack, but it may be useful and it will turn out to fix everything. Because we have been facing problems for half a year, and we don't know what to do about it. facebook/react-native#29978

[dulinriley]

Hi @JerakRus that issue is a bit over-aggregated. For example, the original issue reported was a SIGABRT, but then later people commented with SIGSEGV issues. Also, the original issue was happening with Hermes enabled, but others that commented had JSC enabled. I don't think all of those comments have the same root cause.

If you're seeing a SIGSEGV on null from Hermes, and the stack trace contains hermes_fatal somewhere in it, it's likely to be this other issue instead: #439. A hermes_fatal is most likely associated with the device being Out of Memory (OOM).

As far as this particular issue, it would be good to solve it, but I haven't gotten any response from @raghavyadavm yet about some minimal repro that is open source that I can try using. Without that (or someone else finding a way to reproduce this easily and reliably) I can't make progress on this bug.

[dulinriley]

This issue should be fixed with the migration to the Hades GC in v0.8 and later (corresponding to React Native v0.65 and later).

[harleenarora]

how can do this?