Skip to content

Question about v8 --stack_size #6360

Closed
Closed

Description

@euglv
  • 5.11.0:
  • 64bit:
  • Windows Server 2012-r2:

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)?

Activity

  1. Fishrock123 commented on Apr 24, 2016

    @Fishrock123
    Contributor

    @euglv Please try looking at node --v8-options.

    --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.

  2. ChALkeR commented on Apr 24, 2016

    @ChALkeR
    Member

    It's a v8 feature.

    node --help:

    …
      --v8-options          print v8 command line options
    …
    

    node --v8-options:

    …
      --stack_size (default size of stack region v8 is allowed to use (in kBytes))
            type: int  default: 984
    …
    
  3. changed the title [-]Lack of documentation for stack-size CLI parameter[/-] [+]Question about v8 --stack_size[/+] on Apr 24, 2016
  4. Fishrock123 commented on Apr 24, 2016

    @Fishrock123
    Contributor

    Reopening, as I don't have info to answer the other questions, but other folks here might.

  5. added
    v8 engineIssues and PRs related to the V8 dependency.
    on Apr 24, 2016
  6. mscdex commented on Apr 24, 2016

    @mscdex
    Contributor

    FWIW v8 5.0 (in node v6) has tail call optimizations behind a flag (--es-staging) if recursion is the issue here.

  7. ChALkeR commented on Apr 24, 2016

    @ChALkeR
    Member

    Note: it is still highly not recommended to use flagged features in production.

  8. euglv commented on Apr 24, 2016

    @euglv
    Author

    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.

  9. mscdex commented on Apr 25, 2016

    @mscdex
    Contributor

    @euglv You could also use process.nextTick() or setImmediate() instead of setTimeout(..., 0)

  10. ChALkeR commented on Apr 25, 2016

    @ChALkeR
    Member

    @euglv

    And I definitely need recursion

    Just a reminder: any recursion could be converted to an iterative algorithm. So you probably don't. 😉

  11. bnoordhuis commented on Apr 25, 2016

    @bnoordhuis
    Member

    --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.

  12. louisbuchbinder commented on Sep 15, 2017

    @louisbuchbinder

    @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.

  13. addaleax commented on Sep 15, 2017

    @addaleax
    Member

    @louisbuchbinder You might need to talk to your OS for that; if it’s about Linux and maybe other POSIXes, ulimit -s should be helpful.

  14. louisbuchbinder commented on Sep 15, 2017

    @louisbuchbinder

    Oh interesting thank you for the quick response!

  15. louisbuchbinder commented on Sep 15, 2017

    @louisbuchbinder

    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!

  16. bnoordhuis commented on Sep 16, 2017

    @bnoordhuis
    Member

    @louisbuchbinder

    $ node --v8-options | grep -A1 -w stack_size
      --stack_size (default size of stack region v8 is allowed to use (in kBytes))
            type: int  default: 984
    
  17. gireeshpunathil commented on Sep 16, 2017

    @gireeshpunathil
    Member

    looks like a good requirement for node-report
    ==== Node Report =======================================================

    Event: SIGUSR2, location: "SignalDumpInterruptCallback"
    Filename: node-report.20170517.125940.57943.001.txt
    Dump event time:  2017/05/17 12:59:40
    Module load time: 2017/05/17 12:57:49
    Process ID: 57943
    Thread stack size: 8092M  >> new
    Command line: node -r node-report --stack_size=8286208 --max-old-space-size=200 cpu.js
    
    Node.js version: v7.10.0
    (ares: 1.10.1-DEV, cldr: 30.0.3, http_parser: 2.7.0, icu: 58.2, modules: 51, 
     openssl: 1.0.2k, tz: 2016j, unicode: 9.0, uv: 1.11.0, v8: 5.5.372.43, zlib: 1.2.11)

    /cc @ rnchamberlain

  18. louisbuchbinder commented on Sep 16, 2017

    @louisbuchbinder

    @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.

  19. bnoordhuis commented on Sep 18, 2017

    @bnoordhuis
    Member

    @louisbuchbinder You cannot, not reliably. You could scan process.execArgv but that won't help if the application calls v8.setFlagsFromString('--stack_size=1234').

  20. gireeshpunathil commented on Sep 18, 2017

    @gireeshpunathil
    Member

    @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?

  21. bnoordhuis commented on Sep 18, 2017

    @bnoordhuis
    Member
  22. gireeshpunathil commented on Sep 18, 2017

    @gireeshpunathil
    Member

    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.

  23. milrak commented on Mar 11, 2021

    @milrak

    @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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionIssues asking questions about Node.js.v8 engineIssues and PRs related to the V8 dependency.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions