test-cpu-prof-worker-argv multiple assertion errors #34031
Labels
flaky-test
Issues and PRs related to the tests with unstable failures on the CI.
macos
Issues and PRs related to the macOS platform / OSX.
Comments
rickyes
added
the
flaky-test
|
Seeing it on GitHub Actions CI for macOS too. https://github.com/nodejs/node/pull/34096/checks?check_run_id=815269380 Path: sequential/test-cpu-prof-worker-argv
--- stderr ---
assert.js:103
throw new AssertionError(obj);
^
AssertionError [ERR_ASSERTION]: Expected "actual" not to be strictly deep-equal to: []
at verifyFrames (/Users/runner/runners/2.263.0/work/node/node/test/common/cpu-prof.js:34:10)
at Object.<anonymous> (/Users/runner/runners/2.263.0/work/node/node/test/sequential/test-cpu-prof-worker-argv.js:37:3)
at Module._compile (internal/modules/cjs/loader.js:1217:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1238:10)
at Module.load (internal/modules/cjs/loader.js:1066:32)
at Function.Module._load (internal/modules/cjs/loader.js:954:14)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
at internal/main/run_main_module.js:17:47 {
generatedMessage: true,
code: 'ERR_ASSERTION',
actual: [],
expected: [],
operator: 'notDeepStrictEqual'
}There is a lot of stuff in stdout but GitHub Actions does not make copy/paste for large things easy. (It's entirely possible there is a way to make it easy, but I"m unfamiliar with the interface for the most part.) Here's how it starts: [
{
id: 1,
callFrame: {
functionName: '(root)',
scriptId: '0',
url: '',
lineNumber: -1,
columnNumber: -1
},
hitCount: 0,
children: [ 2, 3, 10, 19, 20, 38 ]
},
{
id: 2,
callFrame: {
functionName: '(program)',
scriptId: '0',
url: '',
lineNumber: -1, |
4 tasks
|
Again on macOS CI today: https://ci.nodejs.org/job/node-test-commit-osx/37895/nodes=osx1015/console |
Failed 5 times in 1000 runs on osx15 and 1 time in 1000 runs on osx14. |
|
Saw it again today at https://ci.nodejs.org/job/node-test-commit-osx/38260/nodes=osx1014/console. |
|
@joyeecheung Based on the output, would you say that the test is valid but should be made more lenient? Or is there a bug somewhere (in Node.js or in the test or in a dependency)? |
|
@Trott Making the test more lenient SGTM, though it's difficult to say what parameters would be good for the CI. Maybe tuning the CPU_PROF_INTERVAL in the test down would help. It might also help to tune the FIB environment variable up so that the workload lasts longer, though that would lead to longer test running time. |
|
This seems to not be failing on macOS in CI anymore (or at least not with noticeable frequency) but has been failing a lot in CI on FreeBSD 12.
Of course, if that approach doesn't fix the test, then we'll have to add more things to try. |
https://ci.nodejs.org/job/node-stress-single-test/324/ EDIT: 76 failures in 1000 runs. |
Trott
added a commit
to Trott/io.js
that referenced
this issue
Feb 19, 2022
Stress test with CPU_PROF_INTERVAL reduced from 50 to 32: https://ci.nodejs.org/job/node-stress-single-test/325/ EDIT: 98 failures so that seems to have made it worse, if anything. |
Trott
added a commit
to Trott/io.js
that referenced
this issue
Feb 19, 2022
Stress test with FIB increased from 30 to 40: https://ci.nodejs.org/job/node-stress-single-test/328/ EDIT: This seems to have fixed it. If it doesn't cause timeouts on the Pi devices, this is probably the way to go. |
Trott
added a commit
to Trott/io.js
that referenced
this issue
Feb 19, 2022
Stress test that does both: https://ci.nodejs.org/job/node-stress-single-test/327/ |
Trott
added a commit
to Trott/io.js
that referenced
this issue
Feb 19, 2022
sxa
pushed a commit
to sxa/node
that referenced
this issue
Mar 7, 2022
Fixes: nodejs#34031 PR-URL: nodejs#42055 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Akhil Marsonya <akhil.marsonya27@gmail.com> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Ricky Zhou <0x19951125@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have encountered this error twice.
The text was updated successfully, but these errors were encountered: