Drive-by refactoring: Make it evident that currently we upload additional files only for Android platform.
Bug: v8:13686
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel
Change-Id: I8081c1185d6a92dfdcef82e697e301f3e7838dc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4205916
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@google.com>
Cr-Commit-Position: refs/heads/main@{#85592}
Since --shared-space is now enabled by default, we don't need this
flag for testing anymore.
Bug: v8:13267
Change-Id: Ib4c1111a75dbf93d05ccf3bac752c0ef089e3c15
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4194715
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85488}
This will allow on the infra side to easier link to the respective
shard on a test failure. Without that it's a hassle to find out on
which shard the failing test ran.
This also simplifies how the global test_config stores information.
Some information was duplicated, but is now rather shared through
properties if the owning object is already present.
Bug: v8:13681
Change-Id: I52f01a4fac74627575d80f25923faba99eb6a1fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4181030
Reviewed-by: Liviu Rau <liviurau@google.com>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85429}
Add custom analysis that is only done if the ClusterFuzz analyzer fails
analyze the stacktrace given without overriding any of its functionality.
Bug: v8:12313
Change-Id: I9e4bc40404387160eb122b8f58999717bd4e7672
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4165085
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85390}
When disabled, Turbofan is fully excluded from the compilation result.
This is expected to reduce V8's contribution to chromium's binary size
by roughly 20%.
If Turbofan is disabled, Maglev and Webassembly must also be disabled
(since both depend on TF).
Note this new configuration (v8_enable_turbofan=false) is not yet
used anywhere - we'll probably enable it for lite_mode bots in an
upcoming CL for test coverage.
Changes in detail:
- Split out all src/compiler files from the main source sets. This
was mostly done already, here we only clean up the few files that
were left.
- Define a new main TF entry point in turbofan.h. `NewCompilationJob`
replaces `Pipeline::NewCompilationJob`.
- When TF is enabled, turbofan-enabled.cc implements the above.
- When disabled, turbofan-disabled stubs out the above with a runtime
FATAL message.
- The build process is modified s.t. mksnapshot always has TF
available since it's needed to generate builtins. When disabled,
TF is removed from other components, in particular it is no longer
included in v8_compiler and transitively in v8_base.
- When disabled, v8_for_testing no longer has v8_initializers
available. These were only needed for test-serialize.cc, which
is now excluded from this build mode.
- When disabled, remove all related cctest/ und unittest/ files from
the build.
Bug: v8:13629
Change-Id: I63ab7632f03d0ee4a787cfc01574b5fdb08fd80b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128529
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85210}
This is a reland of commit ebd933037e
Original change's description:
> [flags,testrunner] Consider readonly flags for conflict detection
>
> Flag conflict detection 1) bails out on incompatible flag values (e.g.
> --jitless and --turbofan) and 2) handles such bailouts transparently in
> the test runner by marking affected tests as OUTCOMES_FAIL.
>
> This CL adds full support for readonly flags to this system, together
> with required additional annotations in variants.py.
>
> Drive-by: assert proper use of v8_enable_slow_dchecks, and add
> support when dcheck_always_on is set.
> Drive-by: introduce has_maglev build variable detection based on
> v8_enable_maglev and use that for .status file annotations.
> Drive-by: protect against unintended overwrites of build variables
> in statusfile.py.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
> Bug: v8:13629,v8:10577
> Change-Id: I04de399139a0490806df8bfee7e75e2ec767b4b5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135879
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85130}
Bug: v8:13629,v8:10577
Change-Id: I49ce322c3fda00a1e1e280d99d2d818772533927
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4151087
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85172}
This reverts commit ebd933037e.
Reason for revert: Breaks a test: https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8792462319927467985/+/u/OptimizeForSize/CreateIsolateFromReadOnlySnapshot
Original change's description:
> [flags,testrunner] Consider readonly flags for conflict detection
>
> Flag conflict detection 1) bails out on incompatible flag values (e.g.
> --jitless and --turbofan) and 2) handles such bailouts transparently in
> the test runner by marking affected tests as OUTCOMES_FAIL.
>
> This CL adds full support for readonly flags to this system, together
> with required additional annotations in variants.py.
>
> Drive-by: assert proper use of v8_enable_slow_dchecks, and add
> support when dcheck_always_on is set.
> Drive-by: introduce has_maglev build variable detection based on
> v8_enable_maglev and use that for .status file annotations.
> Drive-by: protect against unintended overwrites of build variables
> in statusfile.py.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
> Bug: v8:13629,v8:10577
> Change-Id: I04de399139a0490806df8bfee7e75e2ec767b4b5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135879
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85130}
Bug: v8:13629,v8:10577
Change-Id: I0cb072c6c9f05d92894cc0af83c4d1a28df100d5
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147098
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85133}
Flag conflict detection 1) bails out on incompatible flag values (e.g.
--jitless and --turbofan) and 2) handles such bailouts transparently in
the test runner by marking affected tests as OUTCOMES_FAIL.
This CL adds full support for readonly flags to this system, together
with required additional annotations in variants.py.
Drive-by: assert proper use of v8_enable_slow_dchecks, and add
support when dcheck_always_on is set.
Drive-by: introduce has_maglev build variable detection based on
v8_enable_maglev and use that for .status file annotations.
Drive-by: protect against unintended overwrites of build variables
in statusfile.py.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
Bug: v8:13629,v8:10577
Change-Id: I04de399139a0490806df8bfee7e75e2ec767b4b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135879
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85130}
.. since many of these rules are actually relevant when some build
variable is *not* set. Instead of defining an artificial "no_foo"
variable in addition to "foo", allow definition of rules on a negative
build variable condition, e.g.:
"!is_debug": [...]
This new syntax will be used extensively in a followup CL.
Bug: v8:13629,v8:10577
Change-Id: I5ad432e71249b50d15047930e3f9143e872716d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4134247
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85090}
This mode is not used in production any more, and will be removed from
the code base soon. Thus stop executing this variant on bots and remove
the variant definition.
R=machenbach@chromium.org
Bug: v8:13632
Change-Id: I15ff76fa6c5b52f5287e758a80f955ffb1278261
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4127158
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85076}
This is a reland of commit 5d95bd39ca
Original change's description:
> [maglev] Prevent lazy deopts during maglev's JumpLoop (=OSR)
>
> The problem was that synchronous Maglev OSR potentially caused
> code deoptimization during compilation dependency finalization; this
> led to a lazy deopt when returning from the call to
> Runtime_CompileOptimizedOSRFromMaglev. However, a lazy deopt is
> disallowed at this point, since a) Maglev doesn't support marking an opcode as both lazy- and eager deopt, and b) the JumpLoop opcode
> is already marked as eager deopt since that's how OSR is implemented
> under the hood. See also the comment in runtime-compiler.cc.
>
> We fix this by changing synchronous Maglev-to-Turbofan OSR
> behavior s.t. actual OSR compilation is triggered from Ignition
> (and not from Maglev). In other words, when synchronous OSR is
> requested:
>
> 1. trigger an eager deopt from Maglev to Ignition by returning a
> non-null code object from Runtime_CompileOptimizedOSRFromMaglev.
> 2. Ignition handles the pending OSR compile request (through
> osr_urgency).
>
> This CL also reverts previous partial fixes:
>
> This reverts commit 21969e8e24.
> This reverts commit 6bcbcfed5c.
>
> Bug: chromium:1394279,v8:13585,v8:7700
> Change-Id: I3d64aa39575ad806ba2623102092176ca160ef0b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110740
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84922}
Bug: chromium:1394279,v8:13585,v8:7700
Change-Id: Id9d1a1ab2dc36e481287a1a25863b45bf281920c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110746
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84928}
This reverts commit 5d95bd39ca.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20gc%20stress/2101/overview
Original change's description:
> [maglev] Prevent lazy deopts during maglev's JumpLoop (=OSR)
>
> The problem was that synchronous Maglev OSR potentially caused
> code deoptimization during compilation dependency finalization; this
> led to a lazy deopt when returning from the call to
> Runtime_CompileOptimizedOSRFromMaglev. However, a lazy deopt is
> disallowed at this point, since a) Maglev doesn't support marking an opcode as both lazy- and eager deopt, and b) the JumpLoop opcode
> is already marked as eager deopt since that's how OSR is implemented
> under the hood. See also the comment in runtime-compiler.cc.
>
> We fix this by changing synchronous Maglev-to-Turbofan OSR
> behavior s.t. actual OSR compilation is triggered from Ignition
> (and not from Maglev). In other words, when synchronous OSR is
> requested:
>
> 1. trigger an eager deopt from Maglev to Ignition by returning a
> non-null code object from Runtime_CompileOptimizedOSRFromMaglev.
> 2. Ignition handles the pending OSR compile request (through
> osr_urgency).
>
> This CL also reverts previous partial fixes:
>
> This reverts commit 21969e8e24.
> This reverts commit 6bcbcfed5c.
>
> Bug: chromium:1394279,v8:13585,v8:7700
> Change-Id: I3d64aa39575ad806ba2623102092176ca160ef0b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110740
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84922}
Bug: chromium:1394279,v8:13585,v8:7700
Change-Id: Ib82d06ab8281f0e59a2af2b631bf93b25064df1f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110745
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84925}
The problem was that synchronous Maglev OSR potentially caused
code deoptimization during compilation dependency finalization; this
led to a lazy deopt when returning from the call to
Runtime_CompileOptimizedOSRFromMaglev. However, a lazy deopt is
disallowed at this point, since a) Maglev doesn't support marking an opcode as both lazy- and eager deopt, and b) the JumpLoop opcode
is already marked as eager deopt since that's how OSR is implemented
under the hood. See also the comment in runtime-compiler.cc.
We fix this by changing synchronous Maglev-to-Turbofan OSR
behavior s.t. actual OSR compilation is triggered from Ignition
(and not from Maglev). In other words, when synchronous OSR is
requested:
1. trigger an eager deopt from Maglev to Ignition by returning a
non-null code object from Runtime_CompileOptimizedOSRFromMaglev.
2. Ignition handles the pending OSR compile request (through
osr_urgency).
This CL also reverts previous partial fixes:
This reverts commit 21969e8e24.
This reverts commit 6bcbcfed5c.
Bug: chromium:1394279,v8:13585,v8:7700
Change-Id: I3d64aa39575ad806ba2623102092176ca160ef0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110740
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84922}
This replaces the dummy values for the crash analysis. We use the
stack parser from ClusterFuzz to extract the crash type and state from
the stderr of the output and we store it in the test results. We also
added some tests to check the functionality with some example stderrs.
Bug: v8:12313
Change-Id: I67994a752a7aa01cacfb7ebfe7e9d3d61820a4dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4067428
Reviewed-by: Liviu Rau <liviurau@google.com>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84789}
Test ids would get an uniform format between different kinds of tests:
prefix//test_id//suffix
- prefix:
- empty for regular tests
- or 'special test' token, as in 'numfuzz'
- test_id is the full name of the test as generated by test runner:
- suite_name/path/to/actual/test_name
- suffix is anything a test runner processor might want to add to the name:
- numfuzz processor will add 'analysis' of a numeric value
- variant processor will add the variant name
Bug: v8:13316
Change-Id: Ied8f958173f82d8e26c62e39ccc21167ca2928ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4084763
Commit-Queue: Liviu Rau <liviurau@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84736}
Data added:
- subtest_id as it is generated by Processors
- processor_name to trace back the processors that generate subtests
- path of the test
- test_id suffixes introduced by processors:
- numfuzz will have
- an `analysis` suffix for analysis phase
- a number suffix for the variants generated after analysis
- variant processor adds a suffix for every variant
- subtests will inherit suffixes from the parent tests (origin)
V8-Recipe-Flags: resultdb
Cq-Include-Trybots: luci.v8.try:v8_numfuzz_dbg,v8_numfuzz_rel,v8_numfuzz_tsan_compile_rel,v8_numfuzz_tsan_rel
Bug: v8:13316
Change-Id: I67d8b92b575c31b201238cfbcfc76cd076a2f7af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4081127
Commit-Queue: Liviu Rau <liviurau@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84720}
Shared heap is not available without write barriers, therefore skip all
tests that require shared heap when write barriers are disabled.
Change-Id: I66a9a94941ffab792ced964f12df6930b13c92cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079120
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84682}
Drive by: refactor framework_name propagation. The property was already injected in the TestSuite objects. Since it finally got attached to the result record it was natural to have it attached on the TestCase object at creation time. This eliminates the need to inject it through progress objects.
Change-Id: Ic4028d24589a241fb6225dc53ccef2215728d569
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079228
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@google.com>
Cr-Commit-Position: refs/heads/main@{#84670}
Adding the crash status and type to the test result with dummy values,
with the intention of populating these values with data from
ClusterFuzz analyzer or our own logic.
Bug: v8:12313
Change-Id: I8a537734a9c48393b77d582516ae45638986aa55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4047486
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84511}
With shipping lazy compilation, we lose the test coverage for eager
compilation. This is bad, because with PGO, eager compilation may have
a comeback. With this CL we enable eager compilation in the
nooptimization test variant. This variant seems to be the best fit, as
there are no conflicts with existing flags. The --liftoff flag is not a
problem, because Liftoff was anyways the default for eager compilation.
R=clemensb@chromium.org
Bug: v8:12852
Change-Id: I002ecb2a31ad2e2335a0469fdf5e3d5bda3b33bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4027004
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84294}
This CL makes the object keeping stack information thread-local, moving
it from Heap to ThreadLocalTop. In this way, stack scanning will work
correctly when switching between threads, e.g., using v8::Locker.
It also introduces a mechanism for setting a stack marker, to be used
for scanning only the part of stack between its start and the marker
(instead of the current stack top).
Bug: v8:13257
Change-Id: I01091f5f49d9a8143d50aeef53789a98bdb29048
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3960991
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83848}
--use-map-space was already disabled by default. This CL removes
the possibility to enable map space again by removing that flag and
all its usages.
Bug: v8:12578
Change-Id: I8af18f39e9bf645316aa8718b49589eb4b852374
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3959658
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83758}
After removing flag in https://crrev.com/c/3952935 it was still used
on fuzzers.
Bug: v8:12578
Change-Id: I35790b11224c9487923b322f575530159a09b129
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3956734
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83718}
This is a reland of commit 237de893e1
We now guard against requests Python module not being available when running the testrunner. If preconditions (modules & luci context) are not met we no longer add ResultDBIndicator to the chain.
Original change's description:
> [resultdb] Add ResultDB indicator
>
> Adds a new indicator that will send every result to ResultDB (and ultimately in a bq table; to be configured later).
>
> If we are not running in a ResultDB context we introduce only a minimal overhead by exiting early from indicator.
>
> To test these changes in a luci context with ResultDB we activated resultdb feature flag via V8-Recipe-Flags. This feature got implemented in https://crrev.com/c/3925576 .
>
>
> V8-Recipe-Flags: resultdb
> Bug: v8:13316
> Change-Id: I5d98e8f27531b536686a8d63b993313b9d6f62c5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3905385
> Commit-Queue: Liviu Rau <liviurau@google.com>
> Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83672}
V8-Recipe-Flags: resultdb
Bug: v8:13316
Change-Id: I0bdfae13cc7f250c41a18f2d3a513a3bfc580f6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3955263
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Liviu Rau <liviurau@google.com>
Cr-Commit-Position: refs/heads/main@{#83711}
This reverts commit 237de893e1.
Reason for revert: breaks flake bisect:
https://ci.chromium.org/ui/p/v8/builders/try.triggered/v8_flako/b8800423657665797553/overview
The change added the implicit requirement to run testing with
vpython3, which is not given everywhere.
Original change's description:
> [resultdb] Add ResultDB indicator
>
> Adds a new indicator that will send every result to ResultDB (and ultimately in a bq table; to be configured later).
>
> If we are not running in a ResultDB context we introduce only a minimal overhead by exiting early from indicator.
>
> To test these changes in a luci context with ResultDB we activated resultdb feature flag via V8-Recipe-Flags. This feature got implemented in https://crrev.com/c/3925576 .
>
>
> V8-Recipe-Flags: resultdb
> Bug: v8:13316
> Change-Id: I5d98e8f27531b536686a8d63b993313b9d6f62c5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3905385
> Commit-Queue: Liviu Rau <liviurau@google.com>
> Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83672}
Bug: v8:13316
Change-Id: I7e55668e365475298ed46d2fc8ee0fe1282c3e8e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952131
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#83677}
Adds a new indicator that will send every result to ResultDB (and ultimately in a bq table; to be configured later).
If we are not running in a ResultDB context we introduce only a minimal overhead by exiting early from indicator.
To test these changes in a luci context with ResultDB we activated resultdb feature flag via V8-Recipe-Flags. This feature got implemented in https://crrev.com/c/3925576 .
V8-Recipe-Flags: resultdb
Bug: v8:13316
Change-Id: I5d98e8f27531b536686a8d63b993313b9d6f62c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3905385
Commit-Queue: Liviu Rau <liviurau@google.com>
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83672}
All --stress-* flags are now automatically tested. This also removes
a superfluous option that was never changed. The default value is
now inlined.
No-Try: true
Bug: v8:13113
Change-Id: If7428b383ed01ff36a93f618badababfc448db26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899259
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83258}
A recent refactoring changed the behavior of dropping/keeping
results after test execution. The numfuzz loop has previously
treated all results as analysis results, as it expected that others
are dropped. After keeping all results, the second round invalidated
the analysis results and the test loop stopped early.
We now add an additional safeguard that ensures the received result
is indeed associated with an analysis run and do not depend anymore
on result presence/absence.
This also adds all analysis-based instances to the test cases.
No-Try: true
Bug: v8:13295
Change-Id: Ic1ede904d279a0c2b318ec997e7c77542dbc75bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3901812
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83244}
This improves the num-fuzzer system test. Previously, the test
didn't actually start up the main functionality of num-fuzz and
executed 0 tests. Now several of the production fuzzers are used to
run fake test cases. The overall timeout signal, used to
stop numfuzz, is mocked with a counter. The observer signals via the
event method that would have caused the hang fixed in:
https://crrev.com/c/3891373
No-Try: true
Bug: v8:13113
Change-Id: I47d17c1fa2099474079acaad5640228d8c454eb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3893807
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83243}
Based on bots and local testing, MinorMC has reached a stable state in
terms of correctness.
Enable fuzzing with MinorMC to flush out additional issues.
Bug: v8:12612
Change-Id: I9cf8c5791d7256ff63c777b295863506436ee165
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3872265
Reviewed-by: Almothana Athamneh <almuthanna@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83190}
The numfuzz fuzzer.py has a loop to send a new test after receiving
a result. When all test processors go into stopped state, attempts
of sending new tests return False. That case wasn't handled here
and we kept looping forever.
Bug: v8:13113
Change-Id: Ief2686614d9703fb590400ac3e73b6ac9008c8f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3891373
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83188}
Joining a queue-using process can deadlock if the child process is
about to write to the queue, but the parent process wants to join the
child. To fix this, we now drain elements from a separate thread of
the main process.
Bug: v8:13113
Change-Id: Ic279e66ab84eb89a4034ff1f2c025eb850b65013
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3891116
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83177}
A call to cancel_join_thread() is removed as it is suspected to leave
the done_queue with garbled data on process join.
Bug: v8:13113
Change-Id: I85a736cee98d1c2a315efdd468cde216ad848c99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3891251
Reviewed-by: Liviu Rau <liviurau@google.com>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83132}
On termination of the worker pool in the main process, a SIGTERM is
sent from pool to worker. It was meant to terminate long-running
tests in the worker process. The signal handler on the worker side,
however, was only registered during test execution. During the
remaining logic (<1% of the time probably) the default system
behavior for SIGTERM would be used (which will likely just kill
the process). The ungracefully killed process might be killed while
writing to the results queue, which then remains with corrupted data.
Later when the main process cleans up the queue, it hangs.
We now register a default handler in the worker process that catches
the SIGTERM and also gracefully stops the processing loop. Like
that, the SIGTERM signal will always be handled in workers and never
fall back to SIGKILL.
However, a small time window exists when the SIGTERM was caught
right when starting a test process, but when the test-abort handler
was not registered yet. We keep fixing this as a TODO. Worst case,
the main process will block until the last test run is done.
Bug: v8:13113
Change-Id: Ib60f82c6a1569da042c9f44f7b516e2f40a46f93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3882972
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83101}
