test: strengthen test-worker-prof

[gireeshpunathil]

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), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[nodejs-github-bot]

@gireeshpunathil build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/2878/pipeline

[Trott]

An absolute micronit here but maybe add a comment above this (right below the else line) saying this is the parent process?

[Trott]

Looks good to me, but I'd want @addaleax's confirmed sign-off if at all possible first.

[refack]

I'm not confidant in my expertise to properly review this ¯\(ツ)/¯

[gireeshpunathil]

@refack - ack, np; and then I will critically depend on @addaleax's review on this.

In case if this explanation helps:
while the root cause of flakes (profile files missing, insufficient profile ticks) are not fully diagnosed, there is a reasonable and working explanation to that thus:

• there was an issue in the worker in that it was creating isolate in the parent thread as opposed to worker thread itself
• due to this the profile ticks were accounted against parent, not in the worker.
• this test case is a regression test associated with the PR that fixed the issue.
• the test makes use of a parent and a worker. Drive both to run equal amount of time, as much as possible.
• collect the profile output. measure the tick counts from the profile file.
• make sure that the tick counts are comparable.

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 time reaches a threshold) which could potentially result in the tight loop to exit prematurely without the thread really have consumed enough CPU - affecting either or both of the threads. (again, only theory, no real proof for it)

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!

[gireeshpunathil]

CI: https://ci.nodejs.org/job/node-test-pull-request/21561/

[richardlau]

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).

[gireeshpunathil]

just pushed a change to that effect: added debug data in all three assertions + reversed the signal and exit status check order.

[Trott]

${spawnResult} will end up displaying [object Object] unfortunately. You might have to do something like ${util.inspect(spawnResult)} if you want something useful.

[gireeshpunathil]

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 > 
}

[richardlau]

How about passing encoding: 'utf8' option to spawnSync so that stdout and stdin are String objects instead of Buffer objects?

[gireeshpunathil]

@richardlau - addressed your review comments, ptal.

[gireeshpunathil]

@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!

[Trott]

do you have any objections on landing this PR?

I don't have any objections.

[Trott]

Is there anything stopping this up from landing at this point? Or should we land it?

[Trott]

I guess it needs a new CI run.

CI: https://ci.nodejs.org/job/node-test-pull-request/21823/

[gireeshpunathil]

@Trott - I was waiting to see if @refack has a say. At this point I think we should land this, when CI shows us green.

[gireeshpunathil]

Resume Build CI: https://ci.nodejs.org/job/node-test-pull-request/21825/

[gireeshpunathil]

the only failure parallel/test-async-hooks-http-parser-destroy is #26610

[Trott]

Resume Build CI: https://ci.nodejs.org/job/node-test-pull-request/21833/

[gireeshpunathil]

landed as ed849f8