Repository navigation
"Maximum call stack size exceeded" causes a crash in "async_hooks" module #37989
Description
Activity
The following js code can also trigger "Maximum call stack size exceeded":
`async_hooks.createHook({before:new async_hooks.AsyncResource('str').bind(()=>{})}).enable();`» node Welcome to Node.js v14.15.1. Type ".help" for more information. > async_hooks.createHook({before:new async_hooks.AsyncResource('str').bind(()=>{})}).enable(); AsyncHook { [Symbol(init)]: undefined, [Symbol(before)]: [Function: bound runInAsyncScope] { asyncResource: AsyncResource { [Symbol(async_id_symbol)]: 26, [Symbol(trigger_async_id_symbol)]: 5, [Symbol(destroyed)]: [Object] } }, [Symbol(after)]: undefined, [Symbol(destroy)]: undefined, [Symbol(promiseResolve)]: undefined } > RangeError: Maximum call stack size exceeded at emitHook (internal/async_hooks.js:234:5) at emitBeforeScript (internal/async_hooks.js:474:5) at AsyncResource.runInAsyncScope (async_hooks.js:188:5) at emitHook (internal/async_hooks.js:230:38) at emitBeforeScript (internal/async_hooks.js:474:5) at AsyncResource.runInAsyncScope (async_hooks.js:188:5) at emitHook (internal/async_hooks.js:230:38) at emitBeforeScript (internal/async_hooks.js:474:5) at AsyncResource.runInAsyncScope (async_hooks.js:188:5) at emitHook (internal/async_hooks.js:230:38)If any error occurs, an exception or other similar error-reporting stuff should be thrown.
Well, there is a
RangeErrorthrown. it's not catched in your code.
But if you put your before/after handler within a try/catch a real crash happens which is described in #36079- addedasync_hooksIssues and PRs related to the async hooks subsystem.Issues and PRs related to the async hooks subsystem.
on Mar 31, 2021 Well, there is a
RangeErrorthrown. it's not catched in your code.I'm not sure what you mean but the node instance still exits (abnormally) although there has been a RangeError thrown. I don't know if this is a normal behavior.
If any AsyncHook callbacks throw, the application will print the stack trace and exitsee https://nodejs.org/dist/latest-v14.x/docs/api/async_hooks.html#async_hooks_error_handlingLet me try to chip in on this,
You can try to run this in
Nodejs REPLand seelet codeA = `function debug2(...args){fs.writeFileSync(1, \`\${util.format(...args)}\n\`, { flag: 'a' });}async_hooks.createHook({init(asyncId, type, triggerAsyncId, resource) {debug2('init: ',resource);},after(asyncId) {debug2(asyncId);new async_hooks.AsyncResource('str').bind(() => {});},}).enable();`; eval(codeA)
Which is actually just a very simple function
function debug2(...args) { fs.writeFileSync(1, `${util.format(...args)}\n`, { flag: 'a' }); } async_hooks .createHook({ init(asyncId, type, triggerAsyncId, resource) { debug2('init: ', resource); }, after(asyncId) { debug2(asyncId); new async_hooks.AsyncResource('str').bind(() => {}); }, }) .enable();
This would produce (a snippet of it since it keeps repeating)
init: <ref *1> Timeout { _idleTimeout: 15, _idlePrev: [Circular *1], _idleNext: [Circular *1], _idleStart: null, _onTimeout: [Function: flushHistory], _timerArgs: undefined, _repeat: null, _destroyed: false, [Symbol(refed)]: true, [Symbol(kHasPrimitive)]: false, [Symbol(asyncId)]: 73, [Symbol(triggerId)]: 5 } init: { callback: [Function: maybeReadMore_], args: [ ReadStream { connecting: false, _hadError: false, _parent: null, _host: null, _readableState: [ReadableState], _events: [Object: null prototype], _eventsCount: 4, _maxListeners: undefined, _writableState: [WritableState], allowHalfOpen: false, _sockname: null, _pendingData: null, _pendingEncoding: '', server: null, _server: null, init: {aw: true, callback: [Function: afterWriteTick], args: [ 0, { [Symbol(async_id_symbol)]: 5, count: 1,Handle)]: [TTY], cb: [Function: nop],]: false, stream: [WriteStream],Size)]: 0, state: [WritableState]l, } [Symbol(kBuffer)]: null,
I presumed the REPL is ran with some
asyncstuff likesetTimout,process.nextTick()that is causing StackOverflow.Any reason why you would want to do this in REPL?
- added a commit that references this issue
on Jan 13, 2026 - added a commit that references this issue
on Jan 13, 2026 - added a commit that references this issue
on Jan 14, 2026
What steps will reproduce the bug?
Setup a node instance,
and run the following javascript code.
Then the node instance crashes.
How often does it reproduce? Is there a required condition?
This abort can always be triggered following the steps above.
What is the expected behavior?
If any error occurs, an exception or other similar error-reporting stuff should be thrown. There is no reason to abort the whole node process.
What do you see instead?
Additional information