Crash in CPPGC due to illegal memory access

[shiyu zhang]

Hi, I am debugging a CPPGC crash happened occasionally in some memory-heavy scenarios like multiple browser windows with multiple tabs. According to the assembly code, the crash seems to be caused by an illegal memory access, whose address value is kGlobalHandleZapValue. I am new to the CPPGC, does anyone have any clue about the possible reason? Or any suggestions on where should I start for analyzing this kind of GC crash?

Crash stack:

 v8::internal::UnifiedHeapMarkingState::MarkAndPush(v8::TracedReferenceBase const&)

/devcloud/ws/s9NlN/workspace/j_BU8C4IRU/src/out/../../v8/src/heap/cppgc-js/unified-heap-marking-state-inl.h:50:7

v8::internal::UnifiedHeapMarkingVisitorBase::Visit(v8::TracedReferenceBase const&)

/devcloud/ws/s9NlN/workspace/j_BU8C4IRU/src/out/../../v8/src/heap/cppgc-js/unified-heap-marking-visitor.cc:71:31

     x0 = 0x1baffed00baffedf    x1 = 0x0000002003e529f0

     x2 = 0x0000000000000001    x3 = 0x0000005ac52e19f4

     x4 = 0x0000005ada7e4218    x5 = 0x0000000000000004

     x6 = 0x0000000000000000    x7 = 0x0000000000000000

     x8 = 0x1baffed00bac0000    x9 = 0x000000000000000f

    x10 = 0x000000000000000f   x11 = 0x0000000000000000

    x12 = 0x0000000000000000   x13 = 0x0000000000000001

    x14 = 0x0000000000000001   x15 = 0x0000000000000000

    x16 = 0x0000005ac502b800   x17 = 0x0000005a3e4b5494

    x18 = 0x0000000000000000   x19 = 0x1baffed00baffedf

    x20 = 0x0000005ada7e4218   x21 = 0x00000000000002ee

    x22 = 0x0000005ad819f0a0   x23 = 0x0000005ada7e4110

    x24 = 0x0000005ada7e4190   x25 = 0x0000005ada7e41d8

    x26 = 0x0000005a3ea71f00   x27 = 0x0000000653a70612

    x28 = 0x0000005ada7e4100    fp = 0x000008637bd05af5

     lr = 0x0000005ac502b828    sp = 0x0000005ada7e4090

     pc = 0x0000005ac502b834

    Found by: given as instruction pointer in context

Assembly (crash occurred in the red line):

.text:0000000002B24AAC ; v8::internal::UnifiedHeapMarkingVisitorBase::Visit(v8::TracedReferenceBase const&)

.text:0000000002B24AAC _ZN2v88internal29UnifiedHeapMarkingVisitorBase5VisitERKNS_19TracedReferenceBaseE

.text:0000000002B24AAC ; __unwind {

.text:0000000002B24AAC                 HINT            #0x1B

.text:0000000002B24AB0                 STP             X30, X23, [SP,#-0x30]!

.text:0000000002B24AB4                 STP             X22, X21, [SP,#0x10]

.text:0000000002B24AB8                 STP             X20, X19, [SP,#0x20]

.text:0000000002B24ABC                 LDR             X22, [X0,#0x10]

.text:0000000002B24AC0                 LDR             X1, [X1]

.text:0000000002B24AC4                 CBZ             X1, loc_2B24B74

.text:0000000002B24AC8                 LDRB            W2, [X22,#0x19]

.text:0000000002B24ACC                 LDAR            XZR, X0, [X1]

.text:0000000002B24AD0                 BL              _ZN2v88internal12_GLOBAL__N_110MarkObjectENS0_6ObjectERNS1_10TracedNodeENS0_13TracedHandles8MarkModeE ; v8::internal::`anonymous namespace'::MarkObject(v8::internal::Object,v8::internal::`anonymous namespace'::TracedNode &,v8::internal::TracedHandles::MarkMode)

.text:0000000002B24AD4                 MOV             X19, X0

.text:0000000002B24AD8                 TBZ             W19, #0, loc_2B24B74

.text:0000000002B24ADC                 AND             X8, X19, #0xFFFFFFFFFFFC0000

.text:0000000002B24AE0                 LDRB            W9, [X8,#8]

 Value of the suspect address:

    constexpr uint64_t kClearedFreeMemoryValue = 0;

    constexpr uint64_t kZapValue = uint64_t{0xdeadbeedbeadbeef};

    constexpr uint64_t kHandleZapValue = uint64_t{0x1baddead0baddeaf};

    constexpr uint64_t kGlobalHandleZapValue = uint64_t{0x1baffed00baffedf};

[Dominik Inführ]

Hi,

from the stack trace alone it is hard to say what's going on here. If you have a repro we would definitely be happy to take a look as we've seen similar crashes occasionally. Note that from your code listing above it looks like you are using some older version of V8. It could be that upgrading to a newer version fixes this crash.

Best,

Dominik

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/v8-dev/44b72156-7441-444a-8cb8-27ae578f6713n%40googlegroups.com.

[shiyu zhang]

Hi Dominik,

Unfortunately, there is not an easy way to reproduce this crash. Even in our memory-heavy testing scenario, it happens from time to time with a low probability.

 Yes, we are using an old version of V8 embedded in Chromium 114. Do you have any suspect fix patches that we can port and may help mitigating this crash? 

[Dominik Inführ]

Sorry, I don't have concrete patches I could point to.

Best,

Dominik

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/53d95bb2-0ae3-4f12-8e62-1c163ac96902n%40googlegroups.com.