[+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. > -- -- 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/CAKSzg3TJ3MNC-_gHUzxVAA4%3Dtxm7etJkD%2B-_kBg1TtPo_UC8zw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
