start.zig: intentional silent failure when cannot increase stack size

This commit is contained in:
Andrew Kelley 2021-05-28 13:17:04 -07:00
parent 673ae5b457
commit 33a779c7f6

View File

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