I believe crashpad just grabs memory around the registers <https://chromium.googlesource.com/crashpad/crashpad/+/master/snapshot/capture_memory.cc#68> 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.
On Mon, May 13, 2019 at 7:22 AM Jakob Kummerow <jkumme...@chromium.org> wrote: > [+crashpad-dev] > > *From: *irinayat via v8-dev <v8-dev@googlegroups.com> > *Date: *Tue, May 7, 2019 at 1:12 AM > *To: *v8-dev > > 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. >> > -- > 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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/crashpad-dev/CAKSzg3TJ3MNC-_gHUzxVAA4%3Dtxm7etJkD%2B-_kBg1TtPo_UC8zw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CALz_-TaUSzYO2ZeH4g9-8nzJCwnyKF67VveuH%3DfDn6Lna77hYw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
