-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: strengthen test-worker-prof #26608
Conversation
}); | ||
w.postMessage(data); | ||
} else { | ||
tmpdir.refresh(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An absolute micronit here but maybe add a comment above this (right below the else
line) saying this is the parent process?
Looks good to me, but I'd want @addaleax's confirmed sign-off if at all possible first. |
I'm not confidant in my expertise to properly review this ¯\(ツ)/¯ |
@refack - ack, np; and then I will critically depend on @addaleax's review on this. In case if this explanation helps:
The reason for the test failure in my assessment is due to unexpected interplay between the OS scheduler, thread execution order, and the program logic (tight loop until the The new version attempts to run independent of time scale, instead in more deterministic manner , by shuttling some messages a predefined number of times, to get a right mix of CPU and IO. Scheduling and other environmental things should not affect the logic. thanks! |
test/parallel/test-worker-prof.js
Outdated
{ cwd: tmpdir.path }); | ||
assert.strictEqual(spawnResult.stderr.toString(), ''); | ||
assert.strictEqual(spawnResult.status, 0); | ||
assert.strictEqual(spawnResult.signal, null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest swapping this line and the one above it so that the signal is checked first as that would be more useful to know if it is not null rather than the null exit code seen in #26401 (comment).
just pushed a change to that effect: added debug data in all three assertions + reversed the signal and exit status check order. |
test/parallel/test-worker-prof.js
Outdated
assert.strictEqual(spawnResult.stderr.toString(), '', | ||
`child exited with an error: ${spawnResult}`); | ||
assert.strictEqual(spawnResult.signal, null, | ||
`child exited with signal: ${spawnResult}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
${spawnResult}
will end up displaying [object Object]
unfortunately. You might have to do something like ${util.inspect(spawnResult)}
if you want something useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks. Is there any way to explode the internal arrays as well? with this change I get the primitive fields, but not the Buffers:
assert.strictEqual(spawnResult.status, 0,
`child exited with non-zero status: ${util.inspect(spawnResult, {depth: 3})}`);
{ status: 1,
signal: null,
output: [ null, <Buffer >, <Buffer > ],
pid: 72177,
stdout: <Buffer >,
stderr: <Buffer >
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about passing encoding: 'utf8'
option to spawnSync
so that stdout
and stdin
are String objects instead of Buffer objects?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@richardlau - addressed your review comments, ptal.
@refack @Trott - do you have any objections on landing this PR? I am asking this is in the light of reported crash in #26401 (comment) . In my opinion it is a container environment related; however, this test being a pure JS code cannot cause a crash in itself, so should be either native code in node, v8 or elsewhere - which is more of a reason this should land so that we can reproduce, investigate and fix at the source? please let me know! |
I don't have any objections. |
Is there anything stopping this up from landing at this point? Or should we land it? |
I guess it needs a new CI run. |
Resume Build CI: https://ci.nodejs.org/job/node-test-pull-request/21825/ |
the only failure |
Resume Build CI: https://ci.nodejs.org/job/node-test-pull-request/21833/ |
Force main and worker to stay for some deterministic time Add some more validation check around profile file generation Fixes: nodejs#26401 PR-URL: nodejs#26608 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Richard Lau <riclau@uk.ibm.com>
4c7fe07
to
ed849f8
Compare
landed as ed849f8 |
Force main and worker to stay for some deterministic time Add some more validation check around profile file generation Fixes: nodejs#26401 PR-URL: nodejs#26608 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Force main and worker to stay for some deterministic time
Add some more validation check around profile file generation
Refs: #26401
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes