Version
No response
Platform
Observed on the shared-libraries CI configuration.
Subsystem
repl, inspector
What steps will reproduce the bug?
The issue occurs in the inspector-backed REPL introduced by #64034.
ReplInspectorChannel.evaluate() evaluates promise-returning expressions using two inspector commands:
- Runtime.evaluate
- Runtime.awaitPromise
Runtime.evaluate passes:
objectGroup: this.objectGroup
but Runtime.awaitPromise does not.
Under sufficient GC pressure, the remote promise object can be collected between the two inspector calls, causing Runtime.awaitPromise to fail with:
Inspector error -32000: Promise was collected
This is reproducible on the shared-libraries CI configuration where memory pressure is higher.
The existing test that exposes the issue is:
test/parallel/test-repl-pretty-stack-custom-writer.mjs
How often does it reproduce? Is there a required condition?
Not reliably reproducible on normal builds.
Consistently observed on the shared-libraries CI configuration, where GC pressure is higher.
The failure requires a GC cycle to occur between Runtime.evaluate and Runtime.awaitPromise.
What is the expected behavior? Why is that the expected behavior?
The REPL should report the user's actual exception.
Expected output:
The remote promise object should remain available until Runtime.awaitPromise completes.
What do you see instead?
Instead of the user's exception, the inspector reports:
Uncaught Error [ERR_INSPECTOR_COMMAND]:
Inspector error -32000: Promise was collected
This causes test/parallel/test-repl-pretty-stack-custom-writer.mjs to fail.
Additional information
Runtime.awaitPromise accepts an optional objectGroup parameter.
Passing the same object group used by Runtime.evaluate prevents the remote promise object from being collected while the await operation is in progress.
Proposed fix:
return this.postInterruptible('Runtime.awaitPromise', {
__proto__: null,
promiseObjectId: response.result.objectId,
returnByValue: params.returnByValue,
generatePreview: params.generatePreview,
+ objectGroup: this.objectGroup,
}, breakOnSigint);
This issue is related to #64034 (repl: use inspector over vm).
Updating the test to accept ERR_INSPECTOR_COMMAND would mask the underlying issue rather than fix it.
Version
No response
Platform
Subsystem
repl, inspector
What steps will reproduce the bug?
The issue occurs in the inspector-backed REPL introduced by #64034.
ReplInspectorChannel.evaluate() evaluates promise-returning expressions using two inspector commands:
Runtime.evaluate passes:
but Runtime.awaitPromise does not.
Under sufficient GC pressure, the remote promise object can be collected between the two inspector calls, causing Runtime.awaitPromise to fail with:
This is reproducible on the shared-libraries CI configuration where memory pressure is higher.
The existing test that exposes the issue is:
How often does it reproduce? Is there a required condition?
Not reliably reproducible on normal builds.
Consistently observed on the shared-libraries CI configuration, where GC pressure is higher.
The failure requires a GC cycle to occur between Runtime.evaluate and Runtime.awaitPromise.
What is the expected behavior? Why is that the expected behavior?
The REPL should report the user's actual exception.
Expected output:
The remote promise object should remain available until Runtime.awaitPromise completes.
What do you see instead?
Instead of the user's exception, the inspector reports:
This causes test/parallel/test-repl-pretty-stack-custom-writer.mjs to fail.
Additional information
Runtime.awaitPromise accepts an optional objectGroup parameter.
Passing the same object group used by Runtime.evaluate prevents the remote promise object from being collected while the await operation is in progress.
Proposed fix:
return this.postInterruptible('Runtime.awaitPromise', { __proto__: null, promiseObjectId: response.result.objectId, returnByValue: params.returnByValue, generatePreview: params.generatePreview, + objectGroup: this.objectGroup, }, breakOnSigint);This issue is related to #64034 (repl: use inspector over vm).
Updating the test to accept ERR_INSPECTOR_COMMAND would mask the underlying issue rather than fix it.