Crashpad doesn't seem to capture relevant data for V8_FATAL crashes

[irin...@microsoft.com]

We are observing in dumps collected by Crashpad that if the crash was due to V8_Fatal, the relevant data might not be included.

For example, in v8::internal::ConcurrentMarking::Run: 

  current_marked_bytes += visitor.Visit(map, object);

might hit UNREACHABLE() if visitor_id in the map is invalid:  

v8::internal::ConcurrentMarking::Run+0x684 [\v8\src\heap\concurrent-marking.cc @ 821]:

  821 00007ffd`f46738c4 4489bc248c000000 mov     dword ptr [rsp+8Ch],r15d

  821 00007ffd`f46738cc 4c8b20           mov     r12,qword ptr [rax]

  822 00007ffd`f46738cf 488bbc24d0110000 mov     rdi,qword ptr [rsp+11D0h]

  822 00007ffd`f46738d7 418a44240a       mov     al,byte ptr [r12+0Ah]

  822 00007ffd`f46738dc 3c37             cmp     al,37h // case kVisitorIdCount

  822 00007ffd`f46738de 0f8709320000     ja      v8::internal::ConcurrentMarking::Run+0x38ad (00007ffd`f4676aed)  Branch

  

v8::internal::ConcurrentMarking::Run+0x38ad [\v8\src\heap\concurrent-marking.cc @ 879]:

  879 00007ffd`f4676aed 488d0d14291e04  lea     rcx,[(00007ffd`f8859408)]

  879 00007ffd`f4676af4 4c8d059a222704  lea     r8,[(00007ffd`f88e8d95)]

  879 00007ffd`f4676afb 31d2            xor     edx,edx

  879 00007ffd`f4676afd e87e22d701      call    V8_Fatal (00007ffd`f63e8d80)

  

Producing a callstack similar to this:

00 base::win::`anonymous namespace'::ForceCrashOnSigAbort

01 raise

02 v8::base::OS::Abort

03 V8_Fatal

04 v8::internal::ConcurrentMarking::Run

05 base::TaskAnnotator::RunTask

  

It would be useful to see the map and the nearby memory around the bad object to speculate about the possible cause of the corruption. However, even though the local "object" in the frame is captured:

0:014> .frame 4; dv object

04 000000dc`aa7fe1c0 00007ffd`f3efdd57 msedge_child!v8::internal::ConcurrentMarking::Run+0x38c2 [\v8\src\heap\concurrent-marking.cc @ 879] 

(*((v8::internal::HeapObject *)0xdcaa7ff390))

    [+0x000] ptr_             : 0x54f91472b6c1 [Type: unsigned __int64]

the target memory for it isn't included into the dump. 

r12 (see 00007ffd`f46738d7) is pushed onto the stack by raise so can figure it out, but its target memory region is also not included into the dump. Dead end.

What are the heuristics used by Crashpad when determining which data to include into the dump? They seem to work sufficiently well when the crash is caused by a read/write AV directly on a local variable but not when V8_Fatal is involved.

I'd expect to see similar issues with dumps for crashes on CHECK, etc. What could be done to make them more actionable?

[Jakob Kummerow]

[+crashpad-dev]

--
--
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.
For more options, visit https://groups.google.com/d/optout.

[Vlad Tsyrklevich]

I believe crashpad just grabs memory around the registers at the crash site, to improve reporting you could replace V8_Fatal with an immediate call to something like __builtin_trap() at the expense of losing logging.

You received this message because you are subscribed to the Google Groups "Crashpad-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crashpad-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crashpad-dev/CAKSzg3TJ3MNC-_gHUzxVAA4%3Dtxm7etJkD%2B-_kBg1TtPo_UC8zw%40mail.gmail.com.