| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
When I run the test case mentioned in the issue with this change, getting the following error. node: ../deps/uv/src/unix/core.c:556: uv__close_nocheckstdio: Assertion `fd > -1' failed. |
Sorry, something went wrong.
|
With this change in place, test parallel/test-worker-resource-limits is failing with this stack: bash-4.2$ ./node test/parallel/test-worker-resource-limits
Mismatched <anonymous> function calls. Expected exactly 1, actual 0.
at mustCall (/home/harshitha/node/test/common/index.js:325:10)
at Object.expectsError (/home/harshitha/node/test/common/index.js:531:10)
at Object.<anonymous> (/home/harshitha/node/test/parallel/test-worker-resource-limits.js:26:24)
at Module._compile (internal/modules/cjs/loader.js:1208:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1228:10)
at Module.load (internal/modules/cjs/loader.js:1057:32)
at Function.Module._load (internal/modules/cjs/loader.js:952:14)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
at internal/main/run_main_module.js:17:47I believe it is not because of the mismatch in the error code, but because the error callback is not invoked. I am able to recreate with the test in the referenced issue: missing error callback. My original intent with this PR was to covert C++ assertion into an error callback, which is missing! any guidance here? |
Sorry, something went wrong.
|
Getting this currently, I will debug further. bash-4.2$ ./node bar.js 10000
internal/worker.js:191
this.emit('error', new errorCodes[customErr]());
^
TypeError: errorCodes[customErr] is not a constructor
at Worker.[kOnExit] (internal/worker.js:191:26)
at Worker.<computed>.onexit (internal/worker.js:139:62)
|
Sorry, something went wrong.
|
@HarshithaKP Hi! Let me/us know if you need anything to make this PR work :) |
Sorry, something went wrong.
|
@addaleax, Thanks. bash-4.2$ ./node --expose-internals
Welcome to Node.js v14.0.0-pre.
Type ".help" for more information.
> const errorCodes = require('internal/errors').codes
undefined
> const obj = new errorCodes['ERR_WORKER_INIT_FAILED']('foo')
undefined
> obj
Error [ERR_WORKER_INIT_FAILED]: Worker initialization failed: foo
at repl:1:13
at Script.runInThisContext (vm.js:120:20)
at REPLServer.defaultEval (repl.js:436:29)
at bound (domain.js:429:14)
at REPLServer.runBound [as eval] (domain.js:442:12)
at REPLServer.onLine (repl.js:763:10)
at REPLServer.emit (events.js:333:22)
at REPLServer.EventEmitter.emit (domain.js:485:12)
at REPLServer.Interface._onLine (readline.js:329:10)
at REPLServer.Interface._line (readline.js:658:8) {
code: 'ERR_WORKER_INIT_FAILED'
}But when I run the test it is failing. bash-4.2$ ./node bar 10000
internal/worker.js:192
this.emit('error', new errorCodes[customErr]());
^
TypeError: errorCodes[customErr] is not a constructor
at Worker.[kOnExit] (internal/worker.js:192:26)
at Worker.<computed>.onexit (internal/worker.js:140:62)Right now I am stuck here. |
Sorry, something went wrong.
|
@addaleax, thanks again for following up and offer to help! $ cat bar.js const { Worker } = require('worker_threads');
var er = 0
var ex = 0
for (let i = 0; i < +process.argv[2]; ++i) {
const worker = new Worker(
'require(\'worker_threads\').parentPort.postMessage(2 + 2)',
{ eval: true });
worker.on('error', (a, b, c) => {
console.log(`${er++} err'd!`)
console.log(a)
console.log(b)
console.log(c)
})
worker.on('exit', () => {
console.log(`${ex++} exited.`)
})
} |
Sorry, something went wrong.
Instead of hard asserting throw a runtime error, that is more consumable. Fixes: nodejs#31614
Based on the new way of propagating worker initialization failures, modify the tests so as to get specialized error messages.
|
The changes were resulting in node_worker_assertion.js test failure. Fixed it in one more commit. |
Sorry, something went wrong.
Sorry, something went wrong.
|
Landed in 2d3717a 🎉 @HarshithaKP Thanks for persisting and bringing this over the finish line! |
Sorry, something went wrong.
Cover the scenario fixed through nodejs#31621 Unfortunately there is no easy way to test this, in a cross-platform manner. So the approach is: - open a child process with ulimit restriction on file descriptors - in the child process, start few workers - more than the fd limit - make sure some workers fail, with the expected error type. - skip the test in windows, as there is no ulimit there.
Cover the scenario fixed through #31621 Unfortunately there is no easy way to test this, in a cross-platform manner. So the approach is: - open a child process with ulimit restriction on file descriptors - in the child process, start few workers - more than the fd limit - make sure some workers fail, with the expected error type. - skip the test in windows, as there is no ulimit there. Refs: #31621 PR-URL: #31929 Reviewed-By: Denys Otrishko <shishugi@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
Cover the scenario fixed through #31621 Unfortunately there is no easy way to test this, in a cross-platform manner. So the approach is: - open a child process with ulimit restriction on file descriptors - in the child process, start few workers - more than the fd limit - make sure some workers fail, with the expected error type. - skip the test in windows, as there is no ulimit there. Refs: #31621 PR-URL: #31929 Reviewed-By: Denys Otrishko <shishugi@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
Cover the scenario fixed through #31621 Unfortunately there is no easy way to test this, in a cross-platform manner. So the approach is: - open a child process with ulimit restriction on file descriptors - in the child process, start few workers - more than the fd limit - make sure some workers fail, with the expected error type. - skip the test in windows, as there is no ulimit there. Refs: #31621 PR-URL: #31929 Reviewed-By: Denys Otrishko <shishugi@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
Cover the scenario fixed through #31621 Unfortunately there is no easy way to test this, in a cross-platform manner. So the approach is: - open a child process with ulimit restriction on file descriptors - in the child process, start few workers - more than the fd limit - make sure some workers fail, with the expected error type. - skip the test in windows, as there is no ulimit there. Refs: #31621 PR-URL: #31929 Reviewed-By: Denys Otrishko <shishugi@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
| Back | FazBrowse Home | New Git URL |
Instead of hard asserting throw a runtime error,
that is more consumable.
Fixes: #31614
Checklist