SourceMap.findEntry() returns a stale name for a final mapping segment that has no name index

Version

v24.8.0 (present on main; introduced in v15.4.0 / v14.17.1)

Platform

all

Subsystem

module / source maps

What steps will reproduce the bug?

The simplest way to recreate the issue is:

const { SourceMap } = require('node:module');
const sm = new SourceMap({
  version: 3, sources: ['a.js'], names: ['foo'], mappings: 'AAAAA,CAAC',
});
console.log(sm.findEntry(0, 1).name); // prints 'foo'

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

Fails on every run, deterministically.

Required condition: the source map's mappings string must end with a location-only segment (4 fields, no name index), and some earlier segment must have set a name index (i.e. names is non-empty and was referenced before theend). When both hold, findEntry() on that final segment returns the last-seen name instead of undefined

Both conditions are the norm for real minified bundles, so in practice it triggers on essentially every production source map. The minimal repro above (mappings: 'AAAAA,CAAC') is the smallest case that satisfies it.

With --enable-source-maps, the bottom global frame of a stack trace inherits the last-named function instead of being anonymous. Empirically: absent in v14.17.0, appears in v14.17.1 (and v15.4.0), introduced by #36042.

What is the expected behavior? Why is that the expected behavior?

The second segment (CAAC) has only 4 fields and no name index, so findEntry(0, 1).name should be undefined.

What do you see instead?

It returns 'foo', the name from the previous segment.

Additional information

In practice this leads to stack traces being subtly wrong: under --enable-source-maps, the bottom global/anonymous frame is labeled with the last-named function instead of being anonymous. The wrong name is a real identifier from the program, so it looks correct and misleads during debugging rather than being noticed as a defect.

The bug is in SourceMap's #parseMap, it reads the optional 5th (name) VLQ guarded only by !isSeparator(stringCharIterator.peek()). At the end of the mappings string peek() returns '', which is not a separator, so it decodes a phantom VLQ (0), keeps the previous nameIndex, and assigns names[nameIndex] to a segment with no name.

I've implemented a one line fix and I'll open a PR and link it here as soon as it's ready.

PR Link: https://github.com/nodejs/node/pull/63801

Reproduziere das Problem mit dem JavaScript-Snippet im Bericht und untersuche anschließend, wie SourceMap in #parseMap mit dem optionalen name-Feld umgeht. Als erledigt gilt, wenn ein abschließendes Mapping, das nur die Position enthält, undefined als Namen zurückgibt, statt den vorherigen Namen wiederzuverwenden, mit Regressionstests für das minimale Mapping-Beispiel.