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.
