Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34.2k
src,worker: runtime error on loop creation failure#31621
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
Uh oh!
There was an error while loading. Please reload this page.
Conversation
Uh oh!
There was an error while loading. Please reload this page.
HarshithaKP commented Feb 3, 2020
When I run the test case mentioned in the issue with this change, getting the following error. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
1542ff7 to 856372fCompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
HarshithaKP commented Feb 5, 2020 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
With this change in place, test bash-4.2$./nodetest/parallel/test-worker-resource-limitsMismatched<anonymous>functioncalls.Expectedexactly1,actual0.atmustCall(/home/harshitha/node/test/common/index.js:325:10)atObject.expectsError(/home/harshitha/node/test/common/index.js:531:10)atObject.<anonymous>(/home/harshitha/node/test/parallel/test-worker-resource-limits.js:26:24)atModule._compile(internal/modules/cjs/loader.js:1208:30)atObject.Module._extensions..js(internal/modules/cjs/loader.js:1228:10)atModule.load(internal/modules/cjs/loader.js:1057:32)atFunction.Module._load(internal/modules/cjs/loader.js:952:14)atFunction.executeUserEntryPoint[asrunMain](internal/modules/run_main.js:71:12)atinternal/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 |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
HarshithaKP commented Feb 5, 2020
Getting this currently, I will debug further. |
addaleax commented Feb 13, 2020
@HarshithaKP Hi! Let me/us know if you need anything to make this PR work :) |
HarshithaKP commented Feb 14, 2020
@addaleax, Thanks. bash-4.2$./node--expose-internalsWelcometoNode.jsv14.0.0-pre.Type".help"formoreinformation.>consterrorCodes=require('internal/errors').codesundefined>constobj=newerrorCodes['ERR_WORKER_INIT_FAILED']('foo')undefined>objError[ERR_WORKER_INIT_FAILED]: Workerinitialization failed: foo at repl:1:13atScript.runInThisContext(vm.js:120:20)atREPLServer.defaultEval(repl.js:436:29)atbound(domain.js:429:14)atREPLServer.runBound[aseval](domain.js:442:12)atREPLServer.onLine(repl.js:763:10)atREPLServer.emit(events.js:333:22)atREPLServer.EventEmitter.emit(domain.js:485:12)atREPLServer.Interface._onLine(readline.js:329:10)atREPLServer.Interface._line(readline.js:658:8){code: 'ERR_WORKER_INIT_FAILED'}But when I run the test it is failing. bash-4.2$./nodebar10000internal/worker.js:192this.emit('error',newerrorCodes[customErr]());^ TypeError: errorCodes[customErr]isnotaconstructoratWorker.[kOnExit](internal/worker.js:192:26)atWorker.<computed>.onexit(internal/worker.js:140:62)Right now I am stuck here. |
HarshithaKP commented Feb 14, 2020
@addaleax, thanks again for following up and offer to help! $ cat bar.js const{ Worker }=require('worker_threads');varer=0varex=0for(leti=0;i<+process.argv[2];++i){constworker=newWorker('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.`)})} |
Uh oh!
There was an error while loading. Please reload this page.
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.
9eb0ef4 to a214d9cCompareHarshithaKP commented Feb 17, 2020
The changes were resulting in |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
nodejs-github-bot commented Feb 19, 2020
addaleax commented Feb 19, 2020
Landed in 2d3717a 🎉 @HarshithaKP Thanks for persisting and bringing this over the finish line! |
Instead of hard asserting throw a runtime error, that is more consumable. Fixes: #31614 PR-URL: #31621 Reviewed-By: Anna Henningsen <[email protected]>
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.
Instead of hard asserting throw a runtime error, that is more consumable. Fixes: #31614 PR-URL: #31621 Reviewed-By: Anna Henningsen <[email protected]>
Instead of hard asserting throw a runtime error, that is more consumable. Fixes: #31614 PR-URL: #31621 Reviewed-By: Anna Henningsen <[email protected]>
Instead of hard asserting throw a runtime error, that is more consumable. Fixes: #31614 PR-URL: #31621 Reviewed-By: Anna Henningsen <[email protected]>
Instead of hard asserting throw a runtime error, that is more consumable. Fixes: #31614 PR-URL: #31621 Reviewed-By: Anna Henningsen <[email protected]>
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 <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
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 <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
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 <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
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 <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Instead of hard asserting throw a runtime error,
that is more consumable.
Fixes: #31614
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes