18e1eec3d7
The debug_helper library is intended to be used from a debugger process which is attached to the debuggee process that includes V8 content. When reading memory from the debuggee process, debug_helper should use the MemoryAccessor function which reads remote memory rather than dereferencing pointers into the debugger's memory space and potentially crashing. I recently noticed that v8windbg crashes on external strings because the sandbox has been enabled, and the debug_helper code for external strings was incorrectly reading memory from the debugger process rather than the debuggee. You might ask: why wasn't this caught in automated tests? There is a test, cctest/test-debug-helper, which exercises this exact code, but it does so with the debugger and debuggee in the same process. Setting up a proper cross-process test would be much more complex and platform-specific, and this class of bug has never turned up before, so I think the existing test coverage is adequate. Change-Id: Ib8730dd47a925f4229962d27b576a759c5a9a9ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4043821 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#84520} |
||
---|---|---|
.. | ||
BUILD.gn | ||
compiler-types.cc | ||
debug-helper-internal.cc | ||
debug-helper-internal.h | ||
debug-helper.h | ||
debug-macro-shims.h | ||
DEPS | ||
gen-heap-constants.py | ||
get-object-properties.cc | ||
heap-constants.cc | ||
heap-constants.h | ||
list-object-classes.cc | ||
OWNERS | ||
README.md |
V8 debug helper
This library is for debugging V8 itself, not debugging JavaScript running within V8. It is designed to be called from a debugger extension running within a native debugger such as WinDbg or LLDB. It can be used on live processes or crash dumps, and cannot assume that all memory is available in a dump.