You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
=== release test-cpu-prof-worker-argv ===
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'
}
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:
@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.
Activity
Trott commentedon Jun 28, 2020
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,Trott commentedon Dec 14, 2020
Again on macOS CI today:
https://ci.nodejs.org/job/node-test-commit-osx/37895/nodes=osx1015/console
Details
Trott commentedon Dec 14, 2020
Stress test: https://ci.nodejs.org/job/node-stress-single-test/208/
Trott commentedon Dec 14, 2020
Failed 5 times in 1000 runs on osx15 and 1 time in 1000 runs on osx14.
Trott commentedon Jan 6, 2021
Saw it again today at https://ci.nodejs.org/job/node-test-commit-osx/38260/nodes=osx1014/console.
Details
Trott commentedon Jan 6, 2021
@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)?
joyeecheung commentedon Jan 8, 2021
@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.
Trott commentedon Feb 19, 2022
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.
Trott commentedon Feb 19, 2022
https://ci.nodejs.org/job/node-stress-single-test/324/
EDIT: 76 failures in 1000 runs.
Trott commentedon 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 commentedon 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 commentedon Feb 19, 2022
Stress test that does both: https://ci.nodejs.org/job/node-stress-single-test/327/
test: increase Fibonacci argument to 40
test: increase Fibonacci argument to 40
test: increase Fibonacci argument to 40
test: increase Fibonacci argument to 40
test: increase Fibonacci argument to 40