Commit 33a779c7f6
Changed files (1)
lib
std
lib/std/start.zig
@@ -297,9 +297,10 @@ fn posixCallMainAndExit() noreturn {
std.os.linux.tls.initStaticTLS();
}
- // Linux ignores the stack size from the ELF file, and instead always gives 8 MiB.
- // Here we look for the stack size in our program headers and tell the kernel,
- // no, seriously, give me that stack space, I wasn't joking.
+ // The way Linux executables represent stack size is via the PT_GNU_STACK
+ // program header. However the kernel does not recognize it; it always gives 8 MiB.
+ // Here we look for the stack size in our program headers and use setrlimit
+ // to ask for more stack space.
{
var i: usize = 0;
var at_phdr: usize = undefined;
@@ -330,15 +331,14 @@ fn expandStackSize(at_phdr: usize, at_phnum: usize) void {
.cur = wanted_stack_size,
.max = wanted_stack_size,
}) catch {
- // If this is a debug build, it will be useful to find out
- // why this failed. If it is a release build, we allow the
- // stack overflow to cause a segmentation fault. Memory safety
- // is not compromised, however, depending on runtime state,
- // the application may crash due to provided stack space not
- // matching the known upper bound.
- if (builtin.mode == .Debug) {
- @panic("unable to increase stack size");
- }
+ // Because we could not increase the stack size to the upper bound,
+ // depending on what happens at runtime, a stack overflow may occur.
+ // However it would cause a segmentation fault, thanks to stack probing,
+ // so we do not have a memory safety issue here.
+ // This is intentional silent failure.
+ // This logic should be revisited when the following issues are addressed:
+ // https://github.com/ziglang/zig/issues/157
+ // https://github.com/ziglang/zig/issues/1006
};
break;
},