Please take a look at tools/v8windbg/README.md for an overview of what
v8windbg can do and how it's structured. This platform-specific
debugging plugin makes use of the data provided by the V8 postmortem
debugging API in tools/debug_helper.
Note: This code began as https://github.com/billti/v8dbg and then moved
into the Edge repository, where I added features gradually and got code
reviews for individual changes. Now, taken in its entirety, it's an
obnoxiously large CL. I'm open to breaking it up into a few chunks if
that would be preferable.
Bug: v8:9376
Change-Id: I3e503de00bb1aea870ae83e9bd99e4e2eab9ef98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031700
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66319}
This allows CoverageInfo to be distinguished from other kinds of
FixedArray at runtime. I also updated it to use untagged data since it
only stores ints, since that seems like the generally right thing to do
(even though I doubt anybody allocates enough of these to notice the
reduced GC work).
Related Torque changes:
- Allow structs containing untagged data to be used as class fields.
This requires classifying them into the tagged or untagged sections of
the class layout, and checking that their alignment requirements are
met when stored in a packed array.
- Generate a struct containing struct field offsets, so we can ensure
that the layouts defined in Torque and C++ code match. Of course it
would be nice to generate a lot more (indexed accessors, synchronized
accessors, GC visitors, etc.), but we can't do it all at once.
Change-Id: I29e2a2afe37e4805cd80e3a84ef9edfe7ca7bb6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047399
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66318}
This adds tests for the mock logic used in differential fuzzing. The
tests uncovered a couple of issues in the mock files that are also
fixed.
This also does some minor code clean up in the mock code.
Bug: chromium:1044942
Change-Id: I5b67f70f8b104bb681548f742ab863395a88360f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043843
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66304}
This adds 3 flags to the numfuzz fuzzer depending on a probability:
--budget-for-feedback-vector-allocation=0
--interrupt-budget=100
--no-lazy-feedback-allocation
No-Try: true
Bug: v8:10204
Change-Id: I83dabcd0e3ca80bebe596d65d03b3e99d8ecbf03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2060490
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66291}
This reduces the pointer-compression experiment by 3% as it is in
production since a while.
This also uses turbofan when comparing across architectures as tests
run faster and likely find the same or more relevant bugs.
No-Try: true
Change-Id: I35ec97188a101a7cb43454903f7bf9765e57893c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2059995
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66290}
Pass --no-lazy-feedback-allocation in all second runs depending
on a probability. Also combine with --interrupt-budget=100.
This also allows adding several extra flags behind one probability.
The tests are improved to ensure valid flags and configs.
No-Try: true
Bug: v8:10215
Change-Id: I2766ef5044cd8c7096f6b76f39b60b568f550bde
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2059991
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66289}
This skips gay-*.cc cctest files for lint checking. The files
contain 99.9% data not structures. Alternatively, maybe the
data could be moved to non-cc resource files.
This speeds up v8_presubmit without caching locally from 39s to 23s.
This is how it's executed on the continuous CI builder.
No-Try: true
Change-Id: Ide58618a0b1ecd5900b5c9633d584c59b559df32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056463
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66267}
This will allow sharing the configs between Python and JavaScript
based fuzzers.
No-Try: true
Bug: chromium:1044942
Change-Id: Idd47ad31430cfed0629dbb5b9dd5fd2ef8c764f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051951
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66243}
We ensure now that fuzzers don't produce the f.arguments pattern and
instead replace it with a random variable.
No-Try: true
Bug: chromium:1044942, chromium:1020573
Change-Id: I899985f1a238f36d10fb22f76d93b7d5f444eab1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051944
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66238}
Un-ignore some files that only failed in obsolete comparisons.
We don't compare eager anymore and console functions are mocked out
in d8 by now. The exponentiation operator bug doesn't repro anymore.
No-Try: true
Bug: chromium:1044942
Change-Id: I0a572836bc9a4a6aa4736447f638a522ff8e8168
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050400
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66233}
The assumtion that V8 has no output differences within a single line
before a stack overflow, didn't hold. The prefix of e.g. console.info
can lead to a difference in a recursive call.
This change makes foozzie's output capping before a crash work on the
level of characters instead of lines to fix this.
No-Try: true
Bug: chromium:1050942
Change-Id: I13f747caf4f5848d40c31bd4232811285bab3c17
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049844
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66217}
- In log.cc, we used InstructionStart() for code create events, but
the Code object address for code move events. Change to use
InstructionStart() for both.
- The symbol table contains some kind of virtual address, not file
offsets. They happened to be identical in the past but are no longer,
probably due to toolchain changes. Now we use objdump to figure out
the difference between virtual addresses and file offsets.
- When a new code object happened to be created at the same address as
a previous one, we wouldn't update it.
This is indeed wrong, as predicted in a TODO by Jaro.
- For 64bit addresses, using >>> is wrong, now replaced with division.
Change-Id: Ib23114ed736f98bfc33c65004a039a3fd04d3c49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016586
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66145}
The bug appears to be fixed.
No-Try: true
Bug: chromium:693426
Change-Id: Ibd029c906dca87a3fd0c3e00be0b795e87390bd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037439
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66134}
This will allow uploading repro test cases to clusterfuzz for
already suppressed known issues. This will allow tracking if those
issues still reproduce and that suppressions don't become stale.
No-Try: true
Bug: chromium:1044942
Change-Id: I997f11293c51836b97d143b0fea992055b39955e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036083
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66114}
Respective differences were fixed and the suppressions didn't fire
anymore according to the statistics.
No-Try: true
Bug: chromium:664068, chromium:667678
Change-Id: I5e1aa802e0b0288a73d0f236c154289ab45314a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035878
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66100}
Crashes in the presence of RangeError happen often during differential
fuzzing. Until now we have ignored such cases completely.
After this change we compare as much output as possible when one or
both runs have crashed, dramatically increasing the coverage.
No-Try: true
Bug: chromium:1048099
Change-Id: I923c10e9064b5dc6cae1e39a254e221d2867e0e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030914
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66085}
This adds two flags for whitelisting natives on fuzzers:
--allow-natives-for-fuzzing:
Enables a small subset of runtime functions and replaces others with
undefined.
--allow-natives-for-differential-fuzzing
Restricts the allowed runtime functions even further, excluding the
ones that break differential fuzzing.
Bug: chromium:1044942
Change-Id: I890bd4a6ff7c2e483dd74155290a7ace06f85239
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020773
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66068}
We will be able to collect test duration and later upload them in BQ.
Change-Id: Ie5610d4e872259857bf3f26ba698fa65d23058be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020952
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66040}
These both have to do with extremely large numbers, so it's unlikely to cause a problem in practice. Still, correctness.
First, encoding `-2147483648` in VLQ returns the value `"B"`. When decoding, we get the value `1` after reading the base64. We then check if the first bit is set (it is) to see if we should negate it, then we shift all bits right once. Now, `value` will be `0` and `negate` will be `true`. So, we'd return `-0`. Which is a bug! `-0` isn't `-2147483648`, and we've broken a round trip.
Second, encoding any number with the 31st bit set, we'd return the opposite sign. Let's use `1073741824`. Encoding, we get `"ggggggC"`. When decoding, we get the value `-2147483648` after reading the base64. Notice, it's already negative (the 32nd bit is set, because the 31st was set and we shifted everything left once). We'd then check the first bit (it's not) and shift right. But we used `>>`, which does not shift the sign bit. We actually wanted `>>>`, which will. Because of that bug, we get back `-1073741824` instead of the positive `1073741824`. It's even worse if the 32nd and 31st bits are set, `-1610612736` becomes `536870912` after a round trip.
I recently fixed the same two bugs in Closure Compiler: https://github.com/google/closure-compiler/commit/584418eb
Change-Id: Ib6592ad50ae3764479c1a766bbb19042ee83b99d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2018882
Auto-Submit: Justin Ridgewell <jridgewell@google.com>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65987}
This change adds support for the postmortem inspection library to show
the content of cached external strings if that content is available. It
also fixes a minor annoyance where strings with unavailable data would
show up as "...". Now, if fetching the very first character fails, we
omit the literal value from the output.
Bug: v8:9376
Change-Id: Id694a774c231ab3467fb59b1c149284729acfb20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1987922
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65961}
I hit a case where the 'V8_Dcheck' was only the sixth stack frame. Thus
increase the limit from 5 to 7.
R=ahaas@chromium.org
No-Try: true
Change-Id: I1ea37f07ff08ab5acffdfcc89d01ff102750a1e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016589
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65943}
Otherwise, the last tests that ran in a worker keep sitting on their
sigterm handlers without any running processes. This creates
exceptions when workers terminate.
Bug: v8:8292
Change-Id: Iefb9a4a353399c1e3168eae2916e3cedca4e09b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011831
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65907}
This adds a new API function that can be customized by the embedder
by providing a delegate that defines contexts to be measured and
reports the results to JS.
A memory measurement request is carried out as follows:
1) MeasureMemory(delegate) invocation enqueues a new request in
MemoryMeasurement::received_ and schedules a delayed GC task.
2) At the start of the next GC (that is triggered either by the
GC schedule or by the delayed task) each request in received_
moves to processing_. Per-context marking worklists are created
for each native context that was selected by the delegates
(using the ShouldMeasure predicate).
3) At the end of the GC the sizes of the native contexts are
recorded for each request in processing_. The requests move
to the done_ list and result reporting task is scheduled.
4) When the result reporting task runs it invokes the
MeasurementComplete function of each delegate in done_.
Bug: chromium:973627
Change-Id: I0254cae693c5b8fab7c85a9eca0a3a128210b6c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981493
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65856}
The contructor arguments were omitted for Android in a previous
CL, which broke the Android builder.
TBR=tmrts@chromium.org
Bug: v8:8292
Change-Id: I266826e2531ba421161d6cd2241eae34b07e7521
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007494
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65839}
This prints the same details about a process when attempting to kill it
as when termination fails with an exception. This will make it
easier to correlate the two and to see which might be hanging.
Bug: v8:8292
Change-Id: I4b6a50386d4e9d84ded55cf262f19529138654a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2006092
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65837}
When an overall timeout is reached, swarming sends a SIGTERM to
terminate the test runner. The test runner has a signal handler on the
main process to terminate all workers gracefully.
Additionally, every worker process installs a signal handler for
terminating ongoing tests wrapped by command.Command.
Also, command.Command is used on the main process to list tests for
cctest and gtest executables, which led to overriding the test runner's
main signal handler.
This CL disables using signal handlers in commands by default and only
explicitly enables it in safe source locations.
Bug: v8:8292
Change-Id: Ifceadaff75bdd2b77e761498bccbe00b6a3e265c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002528
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65815}
There is no particular reason that PropertyDescriptorObject should be a
subclass of FixedArray. By using a separate struct type, we get better
generated accessor functions, automatic verification, and runtime type
info, plus we save four bytes per instance.
Change-Id: If076782832aa9398806794e4ee6d019aea2f92b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1999463
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65756}
This change moves the definitions of the bitfield flags used by Symbol
and Map to Torque. Symbol could directly follow the pattern established
by SharedFunctionInfo, but Map required some other changes:
- Until now, Torque bitfield definitions have required unsigned types. I
thought that this would be the least-surprising behavior, since we
never sign-extend when decoding bitfield values. However, I believe
that the amount of churn involved in making ElementsKind be unsigned
outweighs the benefit we were getting from this restriction (and
similar difficulties are likely to arise in converting other bitfield
structs to Torque), so this CL updates Torque to allow signed bitfield
values.
- If we try to make Map extend from all of the generated classes that
define its flags, we end up with class sizing problems because some
compilers only apply empty base class optimization to the first in a
row of empty base classes. We could work around this issue by
generating macros instead of classes, but I took this as an
opportunity for a minor clean-up instead: rather than having bitfield
definitions for several different bitfield structs all jumbled
together in Map, they can be split up. I think this makes the code a
little easier to follow, but if others disagree I'm happy to implement
macro generation instead.
Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65701}
This CL factors out the decision-making logic whether a property key should
be treated as a "property" or "element" into LookupIterator::Key, which can
be constructed on its own, allowing use sites to take this distinction into
account before constructing a LookupIterator from the Key, without needing
to duplicate the logic.
This also makes the assortment of LookupIterator constructors more uniform.
Bug: chromium:1031175
Change-Id: I81d7b11ab7e4915f5c05668138e6e0c51ae11821
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962272
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65672}
This change updates CachedTemplateObjectMap, BreakPointInfo, and
BreakPoint to inherit directly from Struct rather than Tuple2 or Tuple3.
It also removes Tuple3 because nothing else used Tuple3. By avoiding
tuple types, we get various benefits that Torque can provide:
- stricter debug verifier functions
- accessors, cast functions, and printers are generated
- BreakPoint and BreakPointInfo have different instance types, so you
can tell them apart at runtime or in a debugger
Change-Id: I9367bc08c6dea55d659fd610f9f6105fd61c907a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988793
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65668}
This is a cleanup to remove unneeded flags after these changes (in
https://crrev.com/c/1988548):
* --future does not imply --wasm-tier-up any more, and
* --wasm-tier-up does not imply --liftoff any more.
Instead, now
* --wasm-tier-up is enabled by default,
* --wasm-tier-up has no effect if --liftoff is not set, and
* --future implies --liftoff.
R=ahaas@chromium.org
Bug: chromium:1040061
Change-Id: I5d04ee1f1d84ddcd0654df0e0a4c6298f80aee9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993280
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65666}
Add jkummerow, thibaudm, zhin; drop titzer.
Also make src/wasm/OWNERS the source of truth and let test-specific
OWNERS files refer to that.
No-Try: true
Change-Id: I9862ae452970e20b7842269721ad6a7953f275fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1989827
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65636}
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 change updates GetObjectProperties to list all of the bitfields
within a class field, if that class field's type is a bitfield struct.
The representation of bitfields in the GetObjectProperties response is
very similar to the representation of struct fields, but with two extra
bytes of data specifying the shift and size of the bitfield.
Bug: v8:9376
Change-Id: I40a22169f3d01652a7f2db8cface43c2a1e30cfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960835
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65610}
Adds --retain option (all, none, json) which controls which files are
kept after running the benchmark.
No-Try: true
Change-Id: I033a8ff7938fd10f8a0fc9425043e24f1229ce0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1980575
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65553}
When V8 throws an uncaught exception, we store a JSMessageObject
with a stack trace and source positions on the isolate itself.
The JSMessageObject can be retrieved by a TryCatch scope
and is used by the inspector to provide additional information to the DevTools
frontend (besides the exception).
Introducing top-level await for REPL mode causes all thrown exceptions
to be turned into a rejected promise. The implicit catch block that does this
conversion clears the JSMessageObject from the isolate as to not leak memory.
This CL preserves the JSMessageObject when the debugger is active and stores
the JSMessageObject on the rejected promise itself. The inspector is changed
to retrieve the JSMessageObject in the existing catch handler and pass the
information along to the frontend.
Drive-by: This CL removes a inspector test that made assumptions when a promise
is cleaned up by the GC. These assumptions no longer hold since we hold on to
the promise longer.
Bug: chromium:1021921
Change-Id: Id0380e2cf3bd79aca05191bc4f3c616f6ced8db7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967375
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65497}
Some test cases stress all global functions and hang when calling
readline.
No-Try: true
Bug: chromium:1034285
Change-Id: I0eaf64437c0806cf3df0a5306aecea4367763cad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967381
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65460}
