nodejs / nodejs/node

Worker with large inline source map aborts process in V8 HandleDebugMagicComments

Ouverte
#64,155 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

v8 engine
Langage dominant
JavaScript
Étoiles
122k
Forks
37.3k
Merge moyen
4 j 2 h
PR mergées (30 j)
283

Description

Version

v26.4.0

Platform
macOS 15.x arm64
Subsystem

worker_threads

What steps will reproduce the bug?

Create a worker entry file with a small amount of executable JavaScript and a very large inline sourceMappingURL=data:... comment, then load it in a worker with a constrained heap.

Minimal repro:

const fs = require("node:fs");
const os = require("node:os");
const path = require("node:path");
const { Worker } = require("node:worker_threads");

const dir = fs.mkdtempSync(path.join(os.tmpdir(), "node-inline-sourcemap-oom-"));

const workerPath = path.join(dir, "worker.cjs");

const source = [
  'const { parentPort } = require("node:worker_threads");',
  'parentPort.postMessage("loaded");',
  'parentPort.close();',
  "",
  "//# sourceMappingURL=data:application/json;base64,",
  "A".repeat(64 * 1024 * 1024),
  "",
].join("\n");

fs.writeFileSync(workerPath, source);

const worker = new Worker(workerPath, {
  resourceLimits: {
    maxOldGenerationSizeMb: 16,
  },
});

worker.on("message", console.log);

worker.on("error", console.error);

worker.on("exit", (code) => {
  console.log("exit", code);
  fs.rmSync(dir, { recursive: true, force: true });
});

Run: node repro.js

How often does it reproduce? Is there a required condition?

It reproduces consistently when the inline sourcemap comment is large enough relative to the worker heap limit.

For comparison, these do not reproduce the same fatal abort:

  1. Keeping the same large payload in an external worker.cjs.map file and using //# sourceMappingURL=worker.cjs.map.
  2. Putting a similarly large payload in a normal non-sourceMappingURL comment.
What is the expected behavior? Why is that the expected behavior?

The worker should fail gracefully, for example by emitting an error event or exiting with a worker failure, without aborting the entire Node.js process.

Ideally, parsing sourceMappingURL / debug magic comments should not internalize an arbitrarily large data URL into V8 old space during module compilation.

What do you see instead?

The whole Node process aborts with an out-of-memory fatal error before the worker can load the module.

Example stack from Node v26.4.0:

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
...
v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawOneByteInternalizedString
v8::internal::FactoryBase<v8::internal::Factory>::NewOneByteInternalizedString
v8::internal::StringTable::LookupKey
v8::internal::FactoryBase<v8::internal::Factory>::InternalizeString
void v8::internal::Parser::HandleDebugMagicComments
v8::internal::Parser::ParseProgram
v8::internal::parsing::ParseProgram
v8::internal::Compiler::GetWrappedFunction
v8::ScriptCompiler::CompileFunction
node::contextify::CompileFunctionForCJSLoader
node::worker::Worker::Run
Additional information

No response

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez par le repro.js fourni et la pile qui passe par V8's Parser::HandleDebugMagicComments, puis comparez les source maps inline et externes sous la limite de tas du worker. Suivez l'entrée du worker via node::worker::Worker::Run et identifiez où se produit l'allocation fatale. C'est terminé lorsque repro n'interrompt plus le processus Node.js et que le worker signale l'échec correctement.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
javascript
Domaine
backend
Type d'issue
Bug
Difficulté
4/5
Temps estimé
3-5 jours
Activité
Calme
Clarté
Plutôt claire
Accessibilité débutants
42/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.