You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can't find any documentation about --stack-size=XXX node.js CLI parameter.
But this parameter seems to have some effect, increasing it to some value eliminates "stack overflow" error. But increasing it more further makes node.js unstable. (It just quits in some time without any error)
So my questions are:
Is XXX in bytes, kilobytes or megabytes?
What is the default value when this parameter is omitted?
What is the minimum and maximum possible values for this parameter?
How operating system (linux/windows) and platform (32bit/64bit) affects this parameter (maximum, minimum, default value)?
--stack_size (default size of stack region v8 is allowed to use (in kBytes))
In normal practice you shouldn't need to adjust this afaik, mind outlining what you are doing? It sounds like you may have recusing tail calls, which are not currently optimized by v8.
Thank you for answers.
So this is the only documentation about this option:
--stack_size (default size of stack region v8 is allowed to use (in kBytes))
type: int default: 984
Yes, cause of "stack overflow" error was recursion in my case. And I definitely need recursion, and recursion steps are definitely limited.
If I run node with --stack-size=1000 - still get "stack overflow" error, but fore some reason if I run node with --stack-size=1200 - in some step of a recursion node crushes silently, without any error at all.
When I searched internet about this issue I saw answers, that on linux node has one particular possiblestack-size limit, under windows - another.
No mention in documentation how large could be stack-size option, and on what it depends.
Finally I figured out how to get rid of "stack overflow" error, without touching stack-size option at all:
var recurciveFunc = function(params) {
/* Some code */
/* ..... */
setTimeout(function(){ recurciveFunc(params) }, 0);
}
If I wrap recursion call in setTimeout - "stack overflow" error disappears.
--stack_size controls what V8 thinks is the stack size, not the actual stack size. It's for overriding the default when the default doesn't match reality. V8's estimate is fairly conservative, there is normally no need to touch it.
If you set it higher than the actual limit, the process gets killed (on UNIX) by a SIGBUS signal when it exceeds the limit.
I'll close, I think that answers the question.
Reacted by Eloff, Nikita Skovoroda and Sebastião Barros
@bnoordhuis Would you mind answering how we can determine the "actual stack size"? Is this simply the unused heap? Or some other machine characteristic? We are considering modifying the stack_limit, but we want to be sure that the change will be stable in production. Thank you.
One more question here. Is there any way to get/print the value of the stack_size option during runtime? In the v8 docs I can see a method to set options from a string, but no mention of getting that value. I am using node6. Thank you!
@bnoordhuis Thank you, but I am trying to print the current value in the process that I have updated. Unfortunately I do not have control of the invocation of my script (that is done by our platform helper process). I am looking for a way to confirm/test that the value I expect to see has actually been updated. It looks like @gireeshpunathil might be on to something with node-report, however I am unfamiliar with that tool.
@louisbuchbinder You cannot, not reliably. You could scan process.execArgv but that won't help if the application calls v8.setFlagsFromString('--stack_size=1234').
Reacted by Louis Buchbinder and Milrak Pereira Pessoa
@bnoordhuis - correct me if I am missing something: a call to pthread_attr_getstacksize is all what is required to get it right? Is it that not all the threads in the process obey --stack_size? or are there other reasons?
o! thanks. I never thought that was what --stack_size is. So the actual thread stack size is different and is controlled natively, while this controls some V8's internal structure for managing code size, method calls etc.
So agree, that measuring the value this flag neither is reliable, nor meaningful.
@louisbuchbinder You cannot, not reliably. You could scan process.execArgv but that won't help if the application calls v8.setFlagsFromString('--stack_size=1234').
Perfect, my solution: gulp build --stack-size=2048
Activity
Fishrock123 commentedon Apr 24, 2016
@euglv Please try looking at
node --v8-options.In normal practice you shouldn't need to adjust this afaik, mind outlining what you are doing? It sounds like you may have recusing tail calls, which are not currently optimized by v8.
ChALkeR commentedon Apr 24, 2016
It's a v8 feature.
node --help:node --v8-options:[-]Lack of documentation for stack-size CLI parameter[/-][+]Question about v8 --stack_size[/+]Fishrock123 commentedon Apr 24, 2016
Reopening, as I don't have info to answer the other questions, but other folks here might.
mscdex commentedon Apr 24, 2016
FWIW v8 5.0 (in node v6) has tail call optimizations behind a flag (
--es-staging) if recursion is the issue here.ChALkeR commentedon Apr 24, 2016
Note: it is still highly not recommended to use flagged features in production.
euglv commentedon Apr 24, 2016
Thank you for answers.
So this is the only documentation about this option:
Yes, cause of "stack overflow" error was recursion in my case. And I definitely need recursion, and recursion steps are definitely limited.
If I run node with
--stack-size=1000- still get "stack overflow" error, but fore some reason if I run node with--stack-size=1200- in some step of a recursion node crushes silently, without any error at all.When I searched internet about this issue I saw answers, that on linux node has one particular possible
stack-sizelimit, under windows - another.No mention in documentation how large could be
stack-sizeoption, and on what it depends.Finally I figured out how to get rid of "stack overflow" error, without touching
stack-sizeoption at all:If I wrap recursion call in
setTimeout- "stack overflow" error disappears.mscdex commentedon Apr 25, 2016
@euglv You could also use
process.nextTick()orsetImmediate()instead ofsetTimeout(..., 0)ChALkeR commentedon Apr 25, 2016
@euglv
Just a reminder: any recursion could be converted to an iterative algorithm. So you probably don't. 😉
bnoordhuis commentedon Apr 25, 2016
--stack_sizecontrols what V8 thinks is the stack size, not the actual stack size. It's for overriding the default when the default doesn't match reality. V8's estimate is fairly conservative, there is normally no need to touch it.If you set it higher than the actual limit, the process gets killed (on UNIX) by a SIGBUS signal when it exceeds the limit.
I'll close, I think that answers the question.
louisbuchbinder commentedon Sep 15, 2017
@bnoordhuis Would you mind answering how we can determine the "actual stack size"? Is this simply the unused heap? Or some other machine characteristic? We are considering modifying the
stack_limit, but we want to be sure that the change will be stable in production. Thank you.addaleax commentedon Sep 15, 2017
@louisbuchbinder You might need to talk to your OS for that; if it’s about Linux and maybe other POSIXes,
ulimit -sshould be helpful.louisbuchbinder commentedon Sep 15, 2017
Oh interesting thank you for the quick response!
louisbuchbinder commentedon Sep 15, 2017
One more question here. Is there any way to get/print the value of the
stack_sizeoption during runtime? In the v8 docs I can see a method to set options from a string, but no mention of getting that value. I am using node6. Thank you!bnoordhuis commentedon Sep 16, 2017
@louisbuchbinder
gireeshpunathil commentedon Sep 16, 2017
looks like a good requirement for node-report
==== Node Report =======================================================
/cc @ rnchamberlain
louisbuchbinder commentedon Sep 16, 2017
@bnoordhuis Thank you, but I am trying to print the current value in the process that I have updated. Unfortunately I do not have control of the invocation of my script (that is done by our platform helper process). I am looking for a way to confirm/test that the value I expect to see has actually been updated. It looks like @gireeshpunathil might be on to something with
node-report, however I am unfamiliar with that tool.bnoordhuis commentedon Sep 18, 2017
@louisbuchbinder You cannot, not reliably. You could scan
process.execArgvbut that won't help if the application callsv8.setFlagsFromString('--stack_size=1234').gireeshpunathil commentedon Sep 18, 2017
@bnoordhuis - correct me if I am missing something: a call to
pthread_attr_getstacksizeis all what is required to get it right? Is it that not all the threads in the process obey--stack_size? or are there other reasons?bnoordhuis commentedon Sep 18, 2017
@gireeshpunathil See #11091 (comment).
gireeshpunathil commentedon Sep 18, 2017
o! thanks. I never thought that was what
--stack_sizeis. So the actual thread stack size is different and is controlled natively, while this controls some V8's internal structure for managing code size, method calls etc.So agree, that measuring the value this flag neither is reliable, nor meaningful.
milrak commentedon Mar 11, 2021
Perfect, my solution:
gulp build --stack-size=2048