Skip to content

Fatal: Check failed: (location_) != nullptr. in node v24.11.1 #60755

@Jayx239

Description

@Jayx239

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs more infoIssues without a valid reproduction.v24.xIssues that can be reproduced on v24.x or PRs targeting the v24.x-staging branch.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions