in debug builds, detect stack overflow at runtime and output a partial stack trace

[schmee]

The following snippet causes a segfaults on my machine:

pub fn main() void {
    const size = 8388608 - 1000;
    const bytes: [size]u8 = undefined;
}

Result:

➜  des git:(master) ✗ zig build-exe des.zig && ./des
[1]    13923 segmentation fault  ./des

I have little experience with low-level languages like this, but I guess this is some sort of stack overflow? If you subtract 10000 instead of 1000, the code runs successfully. I got the random-looking size from #1639 from the discussion of default stack sizes.

Is this intended behavior? Is it PEBKAC? 😄 I have been spoiled so far in Zig with very nice stack traces, would it be possible to have a stack trace for this situation also?

Versions:

➜  des git:(master) ✗ zig version
0.3.0+dfbc063f

macOS Mojave 10.14.3

[sjdh02]

Yep, looks like a stack overflow. Running your code under linux with valgrind and giving it a slightly larger stack works fine. Don't quote me on this, but to give a stack trace for a segfault would probably require a custom signal handler, which Zig should be able to do with cImport for the needed headers on each platform. I'm no Zig expert though, just giving my 2 cents :).

[emekoi]

i did a little work on a crossplatform segfault handler for zig here. i only got it to work usefully on windows because ucontext_t is needed everywhere else.

[andrewrk]

Here's a small example of dumping a stack trace on posix when there is a segfault:

const std = @import("std");
const linux = std.os.linux;

pub fn main() void {
    _ = linux.sigaction(linux.SIGSEGV, &segv_handler_action, null);

    var x = @intToPtr(*i32, 0x1);
    x.* = 42;
}

const segv_handler_action = linux.Sigaction{
    .handler = segv_handler,
    .mask = linux.empty_sigset,
    .flags = linux.SA_RESETHAND,
};

extern fn segv_handler(sig: i32) void {
    std.debug.dumpCurrentStackTrace(null);
}

It doesn't find the restart address of the signal though, which is arguably the most important frame in the stack trace. So that's left to be figured out. I'm sure that's possible.

After that, and after #1047 is done, which will provide applications a way to opt out, I think we can turn on segfault handling by default.

[andrewrk]

Duplicate of #1616