4 ms·
It scares me that passing too little stack space to libc results in such subtle failures.
by TwoBit 6y ago
It scares me that passing too little stack space to libc results in such subtle failures.
- ridiculous_fish 6y agoThis was libc attempting to detect insufficient stack space, under the assumption of a guard page. Go chose to not create a guard page. Nobody can force you to fasten your seatbelt.
- saagarjha 6y agoBut nobody requires that you fasten your seatbelt, either. I believe a stack check is still opt-in using the default flags on most compilers, unless you alloca. Plus, stack probes are merely precautionary, they can still be broken by an inconvenient sequence of stack allocations and signal handlers being run.
- slrz 6y agoNot libc. The stack probe was inserted by the compiler when compiling the vDSO (part of the kernel, but mapped into user processes) with certain ricer^Whardening flags enabled.
- saagarjha 6y agoThis is one of the “gotchas” in C, because the standard doesn’t define anything about the stack at all but it is really quite easy to run into issues if you’re not careful even with “standards compliant” programs. What’s scarier is that this can happen at any function call, and there is no standard way to detect this issue. (Most compilers do support stack probes, though.)
- andi999 6y agoIf there is not enough heap there is the OOM Killer (basically randomly kill processes), also scary.
- jart 6y agoGoogle has a completely different culture from the open source community when it comes to stack. Many FOSS programmers assume an 8mb stack due to a belief that malloc() is slow. Google built all its production services under the assumption of a 64kb stack, because they found a way to make malloc() go fast and wanted to have lots of threads. So it shouldn't be scary or unexpected that there's a little bit of friction bringing those two worldviews in harmony. Google was nice enough to open source tcmalloc.
- deleted 6y ago[deleted]