node
node copied to clipboard
`test-buffer-tostring-rangeerror` is flaky (timeout)
Test
test-buffer-tostring-rangeerror
Platform
Linux x64
Console output
not ok 1244 parallel/test-buffer-tostring-rangeerror
---
duration_ms: 120073.76400
severity: fail
exitcode: -15
stack: |-
timeout
(node:2934155) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
...
Build links
- https://ci.nodejs.org/job/node-test-commit-linux-containered/43366/nodes=ubuntu2204_sharedlibs_withoutintl_x64/
Additional information
No response
I'm able to reproduce locally: running the test 100'000 times, I got 6 timeouts. If I add a console.log("pass") at the end of the file, it gets printed even when the test times out. Adding process.exit(); does not help.
I also investigated this a bit earlier. I was able to reproduce it quite consistently with just a 1000 runs and reduced it to this:
'use strict';
require('../common');
const assert = require('assert');
const { constants: { MAX_STRING_LENGTH } } = require('buffer');
const len = MAX_STRING_LENGTH + 1;
const message = {
code: 'ERR_STRING_TOO_LONG',
name: 'Error',
};
assert.throws(() => Buffer(len).toString('utf8'), message);
assert.throws(() => Buffer(len).toString('utf8'), message);
Removing either the second buffer.toString call, the ../common import, adding a console.log('pass') at the end or using a debug build will make it not reproduce anymore. 🙃 🤔
Could we try to add --no-warnings CLI flag and see if that would have any effect? EDIT: nope, I tried with both --no-warnings and --no-deprecation, and I was still getting timeouts
I got curious again by https://github.com/nodejs/node/pull/52959#issuecomment-2115502995 and indeed this doesn't reproduce on 07f481cfcf1153336534dc5d3cd4c5c9770a72be but does on 91661ec08b so it looks like something in https://github.com/nodejs/node/pull/52293 introduced this flakiness as well / aka probably it's the same root cause.
@fahrradflucht can you try with the --jitless flag?
@fahrradflucht can you try with the
--jitlessflag?
It indeed does not reproduce with --jitless on 91661ec08b5e4c2a538dd36aeac40ae62221a925.
I got curious again by #52959 (comment) and indeed this doesn't reproduce on 07f481c but does on 91661ec so it looks like something in #52293 introduced this flakiness as well / aka probably it's the same root cause.
Actually, I'm sorry, I think I have to take this back. I now reproduced a bunch of times on 07f481cfcf1153336534dc5d3cd4c5c9770a72be as well. It might happen less prior to the v8 update, but it can be reproduced as well.
what environment did you guys reproduce it locally? @aduh95 @fahrradflucht