Prepare gcmole.cc for the next update:
- Print possible GC locations when discovering stale/dead variables
- Make error messages less confusing for the modern V8 engineer
- Prepare gcmole to read suspects.allowlist instead of .whitelist
- Use more readable variable names
- Only log non-found types with --verbose
- Change the currently unusued gccauses format in gcmole.py and
support loading it back in gcmole.cc
- Implemented first basic gc call-chain printing (disabled by default)
GCmole packaging:
- Add debug mode to bootstrap.sh build script
- Update gcmole.py run instructions in bootstrap.sh and package.sh
Bug: v8:10009
Change-Id: I369d48baa2980455d2e8f57e7a803d0384fe83f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3480095
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79357}
- Convert gcmole to python3-ish code
- use local Path implementation for future full migration
- Use optparse and explicit arguments for gcmole
- Add explicit directories flags
- Use backwards compatible env vars as fallbacks
- Add gn target v8_gcmole_files to avoid issues with missing or
incompatible generated files
Drive-by-fixes for running gcmole without ignored files:
- Disable gcmole in Isolate::UnwindAndFindHandle
- Partially disable gcmole in V8HeapExplorer::AddEntry
Bug: v8:10009
Change-Id: I5b4d1c6554db300190226361b6c518419109ff3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497320
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79348}
Tar and Gzip would include timestamps for files in the gcmole package,
which meant that they weren't deterministic across multiple builds. Now
we strip out the timestamps (as well as owner/group information) to make
the packaging more deterministic.
Change-Id: Iec3195ede4150c1603927fec748455329a8da677
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3245112
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77539}
Narrow down the list of owners to choose from in the gcmole auto-update CLs.
Bug: v8:11169
Change-Id: I9f553124c43dc9fc094a8f4a6e2bcc832fe27636
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3236993
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77509}
Change base::Optional to an alias of absl::optional. Eventually we
should remove it entirely.
Bug: v8:11006
Change-Id: I687d44cc7e7cd0a49a84bcc207231eb6808eef2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476318
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76913}
This removes all wasm includes from src/debug and src/inspector if
webassembly is disabled (v8_enable_webassembly=false). It also removes
the definition of {WasmValueObject} and {v8::debug::WasmScript}.
This will allow to later fully exclude the src/wasm directory from
compilation (once other components are fixed).
R=bmeurer@chromium.org, machenbach@chromium.org
Bug: v8:11238
Change-Id: I41a1d83d01fbb6c015cdfd6cc063bad90052505d
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726506
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73138}
To improve performance of parking, keep the thread state in an atomic
variable instead of protecting it with a mutex.
However the mutex was used e.g. to force Unpark() to block while the
safepoint operation was still running. Therefore the safepoint algorithm
has to change as well.
Park() and Unpark() use CAS operation to transition the state.
Safepoint() uses a relaxed load for checking whether a safepoint was
requested. Since Safepoint(), Park() and Unpark() all have a slow path,
there is no need for busy-waiting on the main thread.
We need two more ThreadStates:
* SafepointRequested: This state is set by GlobalSafepoint to force
Running threads into the slow path on Safepoint() and Park(). This
state also replaces the separate atomic<bool> safepoint_requested_
field we used before.
* ParkedSafepoint: This state is set by GlobalSafepoint as well to force
parked threads into the slow path on Unpark().
When stopping all threads, GlobalSafepoint transitions states from
Running --> SafepointRequested and Parked --> ParkedSafepoint to force
the slow path for all three methods. After performing the transition
for each thread we know the exact number of Running threads and wait
until each of them either reached a safepoint or parked itself.
Design doc: https://docs.google.com/document/d/1p9klWyqT_AScAnK_PdHZTcNhZGzoBiYWPkUciIh2C58/edit?usp=sharing
Bug: chromium:1177144, v8:10315
Change-Id: I8697da915c7d18e2fb941f1bedf6181226408feb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704075
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73089}
Make sure gcmole detects issue in DisallowGarbageCollection scopes.
DisallowGarbageCollection is widely used in the codebase to document
code that doesn't allocate. However, this has the rather unexpected
side-effect that gcmole is not run when such a scope is active.
This CL changes the default behavior of gcmole to run even with
DisallowGarbageCollection scopes present. This will give us the best
results of both worlds, dynamic checks by the fuzzer, and static
analysis by gcmole.
To allow crazy local raw pointer operations there is a new
DisableGCMole scope that explicitly disables gcmole.
Change-Id: I0a78fb3b4ceaad35be9bcf7293d917a41f90c91f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615419
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72039}
Improve the performance of gcmole by
* Precompiling the regexes in GCSuspectsCollector.Resolve
* Merging those regexes into a single regex, using '|'
* Changing multiprocess clang plugin invocation to threaded (running
the plugin releases the GIL so this can efficiently thread). This
uses a simple worker pool with a single work queue.
* Change clang plugin invocation loop to yield after each invocation.
This pipelines the dump-callees plugin and GCSuspectsCollector
Parse/Resolve, so that the parse can happen while waiting for other
callee dumps to finish.
Change-Id: Ib9fca70dbcfd2f9d1aebc8bd11aa1d1f7d34e24a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562242
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71617}
Because of LocalHeap safepoints, our existing assert scopes don't
necessarily maintain the same guarantees as desired. In particular,
DisallowHeapAllocation no longer guarantees that objects don't move.
This patch transitions DisallowHeapAllocation to
DisallowGarbageCollection, to ensure that code using this scope is
also protected against safepoints.
Change-Id: I0411425884f6849982611205fb17bb072881c722
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540547
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71319}
This removes the dependency on Lua for running gcmole, and Python's
expressiveness lets us clean up the code a bit, including getting rid
of global variables, embedding the multiprocessing (removing the need
for a separate `parallel.py`), and using difflib for printing the test
expectation diff.
Bug: v8:11169, v8:8590, chromium:1097212
Change-Id: If0ab5ea6f764864855d73cd0ba63cb37c1823955
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543927
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71253}
Add a "combination" assert scope class, which combines multiple existing
assert scopes. This will allow scopes with functional overlap, e.g.
DisallowGarbageCollection and DisallowHeapAllocation, to share an assert
type rather than rather than requiring users to remember to set both. To
demonstrate this, this redefines DisallowGarbageCollection to a
combination of DisallowHeapAllocation and a new DisallowSafepoints, and
some of the DCHECKs checking both are simplified to only check one or
the other, as appropriate.
The combination classes become subclasses of the existing assert scopes,
so that they can be used in their place as e.g. a function parameter,
e.g. DisallowGarbageCollection can be passed to a function expecting
const DisallowHeapAllocation&.
As a drive-by, this also changes the per-thread assert scopes to use a
bitmask, rather than a bool array, to store their per-thread data. The
per-isolate scopes already used a bitmask, so this unifies the
behaviour between the two.
Change-Id: I209e0a56f45e124c0ccadbd9fb77f39e070612fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2534814
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71231}
This resolves issues building gcmole under LLVM 8.0.0 with gcc 10 (see
https://bugs.gentoo.org/708730).
Change-Id: I932def25fb3cc841cf21414a513fbe2a2fa8a8dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2539946
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71204}
GCMole mistakenly thought that GC guards such as DisallowHeapAllocation
covered the whole scope of the function they are declared in. This CL
fixes the false negatives and adds appropriate testing.
Bug: v8:10071
Change-Id: Iffb369977af90ca053a55ca8f451e037a4f460f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2497451
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70763}
This is a reland of 64caf2b0b2
Original change's description:
> [torque] refactor: use -tq only in filenames derived from .tq files
>
> This is to establish a naming rule for Torque-generated files:
> - If the file is called foo/bar-tq..., then it is derived from a
> file foo/bar.tq
> - Otherwise it doesn't belong to a specific .tq file.
>
> So far, we attached -tq to all Torque-generated file names, where it
> sometimes corresponded to a .tq file name and sometimes not.
> It is not necessary to add -tq to file names to indicate that they are
> Torque-generated, since they are already in a directory called
> torque-generated, and we always refer to them as
> "torque-generated/filename", so there is no confusion even though some
> files now have the same name as a corresponding hand-written file, for
> example factory.cc.
>
> TBR: hpayer@chromium.org
> Bug: v8:7793
> Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70060}
Bug: v8:7793
TBR: hpayer@chromium.orgjgruber@chromium.org
Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70137}
Add support for DisallowGarbageCollection scope. This scope will be
introduced once this CL landed.
DisallowGarbageCollection works like DisallowHeapAllocation but also
disallows safepoints.
Bug: v8:10315
Change-Id: Ia7d777d4104b32810dd481ad9dbdf0edd075b6cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2395561
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69881}
GCMole now comes with the long forgotten use-after-free detection
enabled by default. The CL also improves error logging when test
expectations mismatch with the actual output and updates the hash
of GCMole to be used with the newly built version with enabled UAF
detection.
The CL also contains an ignore for isolate.cc due to inability to
fix a warning there and fixes a couple of UAF warnings.
Bug: v8:9680
Change-Id: I7a009ffd5f67b1b5437567691ca4235ea873de70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257236
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68505}
We can't attach a meaningful stack trace to the AggregateError
Promise.any rejects with, but we can augment the individual errors'
stack traces with Promise.any and the index of the corresponding
Promise in the input.
Bug: v8:9808
Change-Id: I7ba754c9b043594decaac8b3a23be74f05c3dffd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198983
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67778}
Most dead variable warnings in GCMole are false positives, either from
failing to detect that TryEvacuateObject returning false means it didn't
allocate, or a regex error thinking that GarbageCollectionReasonToString
causes garbage collection (because the mangled version is something like
GarbageCollectionReasonToString[...]GarbageCollectionReason, and that
matches /Collect.*Garbage/).
Update the whitelist and fix the "Collect.*Garbage" regex to only look
at the function name.
Bug: v8:9985
Change-Id: I62284e97e4975a6a87616d1d535b2ac7958d17bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989829
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65622}
This should help reduce the number of false positives detected
by dead variable analysis.
Bug: v8:9680, chromium:1000635
Change-Id: Id2893dd5f26cad230dede96930a5caacc0272b64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924359
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65186}
This CL ensures we care only about our internal pointer types and not
about raw C++ pointers, because normally special care is taken when
storing raw pointers to the managed heap. Furthermore, checking for raw
pointers produces too many false positives in the dead variable
analysis.
Bug: v8:9680, chromium:1000635
Change-Id: Ica9ea1fe09b7456c011910a6886149b6dfdda1f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924357
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65174}
The bot that runs gcmole was failing before
https://crrev.com/c/1789707 because the test file was missing.
It returned with exit status 0 anyway though. After fixing the
original fault, this CL ensures that the gcmole tests also
trigger an error on the bot(s) if they fail.
R=mstarzinger@chromium.org
CC=mslekova@chromium.org
Change-Id: I29ae40301062baadfcd38b26c336c5749924b0d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789702
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63612}
The bots currently fail to run the gcmole self tests, because the file
is not contained in the generated archive.
This CL fixes that.
R=mstarzinger@chromium.orgCC=mslekova@chromium.org
Change-Id: I691c207be1809516a5cc5e250287427674146a7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789707
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63608}
Since we do not support gcc < 5 any more, we can switch to C++14 now.
Gcmole is the only tool preventing this currently.
R=mstarzinger@chromium.org
Bug: v8:9687, v8:9690
Change-Id: Ie7fee25061bdf6f1e7f156bc150b7142c824f5d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787426
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63595}
Since this produces a few false positives, also implemented a whitelist
mechanism to not report them.
Also, add a couple of tests and implemented automated testing against
test-expectations file.
Bug: v8:9321
Change-Id: I2915a29fe1891e8bbc51118bbd95ae072c8de023
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773243
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63456}
This is a reland of 517ab73fd7
Updates since original: now compressed pointers passed to the function
GetObjectProperties are required to be sign-extended. Previously, the
function allowed zero-extended values, but that led to ambiguity on
pointers like 0x88044919: is it compressed or is the heap range actually
centered on 0x100000000?
Original change's description:
> Add postmortem debugging helper library
>
> This change begins to implement the functionality described in
> https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
> for investigating V8 state in crash dumps.
>
> This change adds a new library, v8_debug_helper, for providing platform-
> agnostic assistance with postmortem debugging. This library can be used
> by extensions built for debuggers such as WinDbg or lldb. Its public API
> is described by debug-helper.h; currently the only method it exposes is
> GetObjectProperties, but we'd like to add more functionality over time.
> The API surface is restricted to plain C-style structs and pointers, so
> that it's easy to link from a debugger extension built with a different
> toolchain.
>
> This change also adds a new cctest file to exercise some basic
> interaction with the new library.
>
> The API function GetObjectProperties takes an object pointer (which
> could be compressed, or weak, or a SMI), and returns a string
> description of the object and a list of properties the object contains.
> For now, the list of properties is entirely based on Torque object
> definitions, but we expect to add custom properties in future updates so
> that it can be easier to make sense of complex data structures such as
> dictionaries.
>
> GetObjectProperties does several things that are intended to generate
> somewhat useful results even in cases where memory may be corrupt or
> unavailable:
> - The caller may optionally provide a type string which will be used if
> the memory for the object's Map is inaccessible.
> - All object pointers are compared against the list of known objects
> generated by mkgrokdump. The caller may optionally provide the
> pointers for the first pages of various heap spaces, to avoid spurious
> matches. If those pointers are not provided, then any matches are
> prefixed with "maybe" in the resulting description string, such as
> "maybe UndefinedValue (0x4288000341 <Oddball>)".
>
> Bug: v8:9376
>
> Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62882}
Bug: v8:9376
Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63008}
This reverts commit 517ab73fd7.
Reason for revert: Test failures https://bugs.chromium.org/p/v8/issues/detail?id=9538
Original change's description:
> Add postmortem debugging helper library
>
> This change begins to implement the functionality described in
> https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
> for investigating V8 state in crash dumps.
>
> This change adds a new library, v8_debug_helper, for providing platform-
> agnostic assistance with postmortem debugging. This library can be used
> by extensions built for debuggers such as WinDbg or lldb. Its public API
> is described by debug-helper.h; currently the only method it exposes is
> GetObjectProperties, but we'd like to add more functionality over time.
> The API surface is restricted to plain C-style structs and pointers, so
> that it's easy to link from a debugger extension built with a different
> toolchain.
>
> This change also adds a new cctest file to exercise some basic
> interaction with the new library.
>
> The API function GetObjectProperties takes an object pointer (which
> could be compressed, or weak, or a SMI), and returns a string
> description of the object and a list of properties the object contains.
> For now, the list of properties is entirely based on Torque object
> definitions, but we expect to add custom properties in future updates so
> that it can be easier to make sense of complex data structures such as
> dictionaries.
>
> GetObjectProperties does several things that are intended to generate
> somewhat useful results even in cases where memory may be corrupt or
> unavailable:
> - The caller may optionally provide a type string which will be used if
> the memory for the object's Map is inaccessible.
> - All object pointers are compared against the list of known objects
> generated by mkgrokdump. The caller may optionally provide the
> pointers for the first pages of various heap spaces, to avoid spurious
> matches. If those pointers are not provided, then any matches are
> prefixed with "maybe" in the resulting description string, such as
> "maybe UndefinedValue (0x4288000341 <Oddball>)".
>
> Bug: v8:9376
>
> Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62882}
TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com
Change-Id: Ia078f2e8d101d2375b5db88021b2d65d28f1b075
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9376
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716033
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62899}
This change begins to implement the functionality described in
https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
for investigating V8 state in crash dumps.
This change adds a new library, v8_debug_helper, for providing platform-
agnostic assistance with postmortem debugging. This library can be used
by extensions built for debuggers such as WinDbg or lldb. Its public API
is described by debug-helper.h; currently the only method it exposes is
GetObjectProperties, but we'd like to add more functionality over time.
The API surface is restricted to plain C-style structs and pointers, so
that it's easy to link from a debugger extension built with a different
toolchain.
This change also adds a new cctest file to exercise some basic
interaction with the new library.
The API function GetObjectProperties takes an object pointer (which
could be compressed, or weak, or a SMI), and returns a string
description of the object and a list of properties the object contains.
For now, the list of properties is entirely based on Torque object
definitions, but we expect to add custom properties in future updates so
that it can be easier to make sense of complex data structures such as
dictionaries.
GetObjectProperties does several things that are intended to generate
somewhat useful results even in cases where memory may be corrupt or
unavailable:
- The caller may optionally provide a type string which will be used if
the memory for the object's Map is inaccessible.
- All object pointers are compared against the list of known objects
generated by mkgrokdump. The caller may optionally provide the
pointers for the first pages of various heap spaces, to avoid spurious
matches. If those pointers are not provided, then any matches are
prefixed with "maybe" in the resulting description string, such as
"maybe UndefinedValue (0x4288000341 <Oddball>)".
Bug: v8:9376
Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62882}
