Segmentation fault when increasing the stack size on Windows 7

[a-roberts]

Reproduce:
node --stack-size=3000 -p ''.

Version: any Node version.
Platform: Windows 7 64-bit and I'm using Git bash. With a regular command prompt (cmd.exe), the command returns instantly with no output: including with node --stack-size=3000 -p process.
Subsystem: my guess is V8.

For background we've been running CITGM and hit the RangeCheck call stack size exceeded problem on all platforms with CITGM so increased the stack size to 5k to actually run CITGM successfully. Then noticed the seg faults on Windows 7 only.

Suggested plan:

• Ensure we're getting dump files for analysis to give us further clues). Checked at the usual places on Windows and can't see any
• Attach a debugger to V8 and compare behaviour when it works and when it doesn't
• Get our pointer addresses and use gdb (I'm used to Linux debugging so find an awesome Windows equivalent if not available) on the attached process to check we can access this memory (in our address space)
• Check the mmap operation's are legit (to and from addresses)
• Why Windows 7 only? I don't see this on Windows 2012, 2016, 8 or 10

@gibfahn @bnoordhuis @mhdawson

[bnoordhuis]

It seems to be a common misunderstanding but --stack_size=... doesn't change the size of the stack, it tells node/V8 how big it is. If you set it to a value that's bigger than the actual size, it runs over.

It's been discussed in the past to make it change the stack size (and I even remember writing some code to that effect) but ultimately it never happened.

[gibfahn]

It seems to be a common misunderstanding but --stack_size=... doesn't change the size of the stack, it tells node/V8 how big it is. If you set it to a value that's bigger than the actual size, it runs over.

How does it run over so quickly? I'd have thought it would blow when the stack grew past a certain amount, rather than immediately.

[gireeshpunathil]

a wild guess is that v8 may be writing some housekeeping stuff at the floor of the stack after doing the math (roof + --stack_size) , but lands up in an unmapped area?

Can be easily verified if you have the core dump with you - launch it in windbg and look at the stack bounds, current rspand what code is accessing it.

[bnoordhuis]

I suppose we should close this out because ultimately there's no bug to fix. If someone wants to change --stack_size from "assume this big" to "make this big", please open a feature request or pull request.

[sneurlax]

This is occurring for me on Linux today, as well, when using a stack-size over 327680000.