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? -- -- v8-dev mailing list v8-dev@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.