Version
v26.10.0 and v24.21.0 (official win-x64 builds); v22.22.2 on Linux x64; first seen on v24.16.0 and on Node 24.20.0 as embedded in Electron 43.6.0
Platform
Windows 10 22H2 x64 (build 19045.6466), 64 GB RAM; also Linux x86_64
Subsystem
buffer
What steps will reproduce the bug?
const big = Buffer.alloc(2 ** 31 + 4096, 97);
const hit = 2 ** 31 + 100;
big[hit] = 10;
console.log(big.indexOf(10, 2 ** 31 + 50)); // number needle
console.log(big.indexOf(Buffer.from([10]), 2 ** 31 + 50)); // Buffer needle
console.log(big.indexOf('\n', 2 ** 31 + 50)); // string needleFull script with a below-2 GiB control: indexof_2gib.js in https://gist.github.com/BlackWhiteYellow/f44e367254db24fbe20d7fe10002ab1f (needs ~4.5 GB of free RAM).
How often does it reproduce? Is there a required condition?
Always, when the match position is ≥ 2^31, on every version and platform listed above. Matches below 2^31 in a buffer just under 2 GiB are returned correctly.
What is the expected behavior? Why is that the expected behavior?
2147483748, the byte offset of the match. Buffer.alloc accepts lengths above 2^31 on 64-bit, so indexOf should return offsets in that range, as documented for the method.
What do you see instead?
-2147483548 for all three needle types, which equals 2147483748 − 2^32 (the offset truncated to int32).
Additional information
Consumers that treat only -1 as "not found" then move their cursor backwards; in the Claude Code VS Code extension this turns into an endless re-parse loop and an out-of-memory crash of the editor's extension host (downstream report linked in a comment below). #62711 (commit 49198d2, the fix for #62873) changed how the end parameter of indexOf/lastIndexOf is handled; it does not change how the found position is returned.
Version
v26.10.0 and v24.21.0 (official win-x64 builds); v22.22.2 on Linux x64; first seen on v24.16.0 and on Node 24.20.0 as embedded in Electron 43.6.0
Platform
Subsystem
buffer
What steps will reproduce the bug?
Full script with a below-2 GiB control:
indexof_2gib.jsin https://gist.github.com/BlackWhiteYellow/f44e367254db24fbe20d7fe10002ab1f (needs ~4.5 GB of free RAM).How often does it reproduce? Is there a required condition?
Always, when the match position is ≥ 2^31, on every version and platform listed above. Matches below 2^31 in a buffer just under 2 GiB are returned correctly.
What is the expected behavior? Why is that the expected behavior?
2147483748, the byte offset of the match.Buffer.allocaccepts lengths above 2^31 on 64-bit, soindexOfshould return offsets in that range, as documented for the method.What do you see instead?
-2147483548for all three needle types, which equals2147483748 − 2^32(the offset truncated to int32).Additional information
Consumers that treat only
-1as "not found" then move their cursor backwards; in the Claude Code VS Code extension this turns into an endless re-parse loop and an out-of-memory crash of the editor's extension host (downstream report linked in a comment below). #62711 (commit 49198d2, the fix for #62873) changed how theendparameter of indexOf/lastIndexOf is handled; it does not change how the found position is returned.