diff options
| -rw-r--r-- | lib/std/start.zig | 24 |
1 files changed, 12 insertions, 12 deletions
diff --git a/lib/std/start.zig b/lib/std/start.zig index 250dea6a7b..389caf8da1 100644 --- a/lib/std/start.zig +++ b/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; }, |