-
-
Notifications
You must be signed in to change notification settings - Fork 33.9k
Description
Version
v24.11.1
Platform
Linux <redacted_host_name> 6.14.0-35-generic #35~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Oct 14 13:55:17 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
npm run test:integ
package.json:
{
...
"scripts": {
...
"test:integ": "node --test --test-concurrency=1 ./integ/*integ.ts"
}
...
Output:
#
# Fatal error in , line 0
# Check failed: (location_) != nullptr.
#
#
#
#FailureMessage Object: 0x7c5452bf45f0
----- Native stack trace -----
1: 0x942cf1 [/home/jmoney/.nvm/versions/node/v24.11.1/bin/node]
2: 0x2684403 V8_Fatal(char const*, ...) [/home/jmoney/.nvm/versions/node/v24.11.1/bin/node]
3: 0x119e9b3 [/home/jmoney/.nvm/versions/node/v24.11.1/bin/node]
4: 0xc0a160 [/home/jmoney/.nvm/versions/node/v24.11.1/bin/node]
5: 0x7c5353e76576
How often does it reproduce? Is there a required condition?
I have seen this before while testing pre-release 24 versions, but am seeing this consistently while running node --test. The behavior is oncisistent, where sometimes this occurs 1 out of 6 tests, and other times 3 out of 6 tests fail. I have not debugged too deep, so I am not really sure what conditions are causing this.
That being said, one of my hunches is that this has to do with a bug in thread workers or the exec/spawn process functionality. I have created a library that wraps thread workers and process methods to provide a facade for parralel execution, so I think that this may be a result of failures in some of the system calls. Regardless, I don't think that nodejs users should be able to trigger unhandled faults in the nodejs runtime like this.
What is the expected behavior? Why is that the expected behavior?
The expected behavior is that node js does not have internal failures from application layer runtime behavior.
What do you see instead?
#
# Fatal error in , line 0
# Check failed: (location_) != nullptr.
#
#
#
#FailureMessage Object: 0x7c5452bf45f0
----- Native stack trace -----
1: 0x942cf1 [/home/<userName>/.nvm/versions/node/v24.11.1/bin/node]
2: 0x2684403 V8_Fatal(char const*, ...) [/home/<userName>/.nvm/versions/node/v24.11.1/bin/node]
3: 0x119e9b3 [/home/<userName>/.nvm/versions/node/v24.11.1/bin/node]
4: 0xc0a160 [/home/<userName>/.nvm/versions/node/v24.11.1/bin/node]
5: 0x7c5353e76576
Additional information
The nature of the library I am testing performs a lot of file system operations, as well as some parralel execution mostly with thread workers if this can help narrow down the scope. It is a private library right now so the code is not publically accessible for review, but I can provide examples or code snippets as necessary to debug.
dependencies
"dependencies": {
"<myFork>/express": "^4.19.2",
"@swizzyweb/oauth-middleware": "^0.1.1",
"@swizzyweb/quirk": "^0.1.3", // Unreleased parralel computing library
... (other first party dependencies of mine)
"jsonpath-plus": "^10.3.0",
"typescript": "^5.9.3"
},
"devDependencies": {
"@swizzyweb/swerve": "^0.5.8",
"@types/jest": "^30.0.0",
"@types/jsonpath-plus": "^5.0.5",
"@types/node": "^22.18.8",
"@types/supertest": "^6.0.3",
"jest": "^30.2.0",
"supertest": "^7.1.4",
"ts-jest": "^29.4.4",
"ts-node-dev": "^2.0.0"
}