Bring windows segfault handler on par with linux #4319

Rocknest · 2020-01-29T16:03:29Z

Adds a new way to dump stack traces on windows that closely resembles linux segfault handler. Works on i386, x86_64 (tested) and aarch64 (not tested).

I don't know where to put these definitions since there are no 'bits' for windows by architecture.

Basically changes are only seen on i386. Test code:

pub fn main() void {
    test1();
}

fn test1() void {
    illegal();
}

fn illegal() void {
    asm volatile ("nop");
    asm volatile ("ud2");
}

Before:

D:\zig>zig run ill.zig -target i386-windows-gnu
Illegal Instruction

After:

D:\zig>zig run ill.zig -target i386-windows-gnu
Illegal instruction at address 0xb6b034
D:\zig\ill.zig:10:5: 0xb6b034 in illegal (run.o)
    asm volatile ("nop");
    ^
D:\zig\ill.zig:6:12: 0xb64a17 in test1 (run.o)
    illegal();
           ^
D:\zig\ill.zig:2:10: 0xb52a97 in main (run.o)
    test1();
         ^
D:\zig\lib\zig\std\start.zig:125:65: 0xb519e2 in std.start.WinMainCRTStartup (run.o)                             
    std.os.windows.kernel32.ExitProcess(initEventLoopAndCallMain());
                                                                ^
???:?:?: 0x74f76358 in ??? (???)
???:?:?: 0x777d7b73 in ??? (???)
???:?:?: 0x777d7b43 in ??? (???)
!integer overflow
!D:\zig\lib\zig\std\debug.zig:140:65: 0xb6adbd in std.debug.dumpStackTraceFromBase (run.o)
!        printSourceAtAddress(debug_info, stderr, return_address - 1, tty_config) catch return;
!                                                                ^
!D:\zig\lib\zig\std\debug.zig:2331:31: 0xb649ca in std.debug.handleSegfaultWindowsExtra (run.o)
!        dumpStackTraceFromBase(regs.bp, regs.ip);
!                              ^
!D:\zig\lib\zig\std\debug.zig:2313:76: 0xb52a7a in std.debug.handleSegfaultWindows (run.o)
!        windows.EXCEPTION_ILLEGAL_INSTRUCTION => handleSegfaultWindowsExtra(info, 2, null),
!                                                                           ^
!???:?:?: 0x777dbba5 in ??? (???)
!???:?:?: 0x777d808a in ??? (???)
!???:?:?: 0x777e4215 in ??? (???)
!D:\zig\ill.zig:6:12: 0xb64a17 in test1 (run.o)
!    illegal();
!           ^
!D:\zig\ill.zig:2:10: 0xb52a97 in main (run.o)
!    test1();
!         ^
!D:\zig\lib\zig\std\start.zig:125:65: 0xb519e2 in std.start.WinMainCRTStartup (run.o)
!    std.os.windows.kernel32.ExitProcess(initEventLoopAndCallMain());
!                                                                ^
!???:?:?: 0x74f76358 in ??? (???)
!???:?:?: 0x777d7b73 in ??? (???)
!???:?:?: 0x777d7b43 in ??? (???)

Highlighted is a panic caused by underflow in dumpStackTraceFromBase when it received 0 from StackIterator. I'm sure its a bug.

There is also a problem that stack trace points to "nop" and not "ud2" instruction.

LemonBoy · 2020-01-29T16:43:37Z

lib/std/debug.zig

        else => return windows.EXCEPTION_CONTINUE_SEARCH,
    }
 }

+// zig won't let me use an anon enum here


Why is that? What error does it give?

D:\zig>zig run ill.zig -target x86_64-windows-gnu .\lib\zig\std\debug.zig:2311:85: error: expected type 'std.debug.enum:2320:80', found 'std.debug.enum:2320:80' windows.EXCEPTION_DATATYPE_MISALIGNMENT => handleSegfaultWindowsExtra(info, .fmt, "Unaligned Memory Access"), ^ .\lib\zig\std\debug.zig:2320:80: note: std.debug.enum:2320:80 declared here fn handleSegfaultWindowsExtra(info: *windows.EXCEPTION_POINTERS, comptime msg: enum {fmt, segv, ill}, comptime format: ?[]const u8) noreturn {

Ah the infamous enum bug, I think it stops being a problem if you don't make it a comptime param.

Nope, comptime does not make a difference

Is there an issue for this? I'll take a look

#3707, the anonymous enum is analyzed twice and produces two disjoint types.

lib/std/debug.zig

andrewrk · 2020-01-29T17:33:43Z

There is also a problem that stack trace points to "nop" and not "ud2" instruction.

Could this be related to 7336b75?

Rocknest · 2020-01-29T19:34:09Z

@andrewrk no, that function actually not even called once when i tested.

I've managed to make it work, now it points to ud2 asm block. I have no idea why adding 1 to ip fixes it. Also stack iterator won't return nulls now.

D:\zig>zig run ill.zig -target i386-windows-gnu
Illegal instruction at address 0xdeb054
D:\zig\ill.zig:10:5: 0xdeb055 in illegal (run.o)
    asm volatile ("ud2");
    ^
D:\zig\ill.zig:6:12: 0xde4a17 in test1 (run.o)
    illegal();
           ^
D:\zig\ill.zig:2:10: 0xdd2a97 in main (run.o)
    test1();
         ^
D:\zig\lib\zig\std\start.zig:125:65: 0xdd19e2 in std.start.WinMainCRTStartup (run.o)
    std.os.windows.kernel32.ExitProcess(initEventLoopAndCallMain());
                                                                ^
???:?:?: 0x74f76358 in ??? (???)
???:?:?: 0x777d7b73 in ??? (???)
???:?:?: 0x777d7b43 in ??? (???)

D:\zig>

andrewrk · 2020-01-29T19:39:07Z

Thanks @Rocknest. This looks like a good change. Happy to merge after @LemonBoy's review comment #4319 (comment) is solved

LemonBoy · 2020-01-29T21:16:52Z

I've managed to make it work, now it points to ud2 asm block. I have no idea why adding 1 to ip fixes it.

Hold your horses, this is not correct. Get a debugger and you'll see that the exception address is indeed correct and points to the ud2 instruction, there's something fishy in the debug info and/or its handling.

Rocknest · 2020-01-29T21:21:59Z

@LemonBoy Yes the instruction is exactly where ip points to, but it looks like there is some extra -1 in printSourceAtAddress which is causing off by one error.

LemonBoy · 2020-01-29T21:25:30Z

Yes the instruction is exactly where ip points to, but it looks like there is some extra -1 in printSourceAtAddress which is causing off by one error.

There's no -1 in printSourceAtAddressWindows, the -1 offset is needed only when you're dealing with return addresses as you may be past the function boundary, but this is not the case as you have the ip.

Rocknest · 2020-01-29T21:34:45Z

@LemonBoy i suspect that off-by-one is debug.zig:474. <= instead of <.

LemonBoy · 2020-01-29T21:40:18Z

i suspect that off-by-one is debug.zig:472. <= instead <.

If the comment above is to be trusted then yes, it should be <. I don't know too much about pdbs to say if that's correct or not, try it and see? :)

andrewrk · 2020-01-29T21:42:15Z

The comment is from a60ecdc

Rocknest · 2020-01-29T21:55:28Z

Looks like that's a proper fix. Stack traces look identical to linux (up to main fn).

andrewrk · 2020-01-29T22:29:05Z

💯 Wonderful. Thank you both.

Nevermind the sr.ht build failure. It appears to be a temporary CI issue.

lib/std/os/windows/bits.zig

andrewrk · 2020-01-30T03:12:29Z

lib/std/os/windows/bits.zig

+            LastExceptionFromRip: DWORD64,
+
+            pub fn getRegs(ctx: *const CONTEXT) struct {bp: usize, ip: usize} {
+                return .{.bp = @intCast(usize, ctx.Rbp), .ip = @intCast(usize, ctx.Rip)};


@intCast not needed here

I've got another nonsensical compile error

D:\zig>zig run ill.zig .\lib\zig\std\os\windows\bits.zig:1036:29: error: array access of non-array type 'std.os.windows.bits.struct:1035:49' return .{ctx.Rbp, ctx.Rip}; ^

Generally the thing to do is to mark a workaround like this:

// TODO: The @as is a workaround for https://github.com/ziglang/zig/issues/4310 return .{.bp = @as(usize, ctx.Rbp), .ip = @as(usize, ctx.Rip)};

(replace 4310 with the issue number corresponding to this bug)

Does @as provide a workaround? That would be a preferable workaround to @intCast.

Its a confusing compile error. Actually the problem is that anon list literal cannot coerce into given type.

I think it is #4148

lib/std/os/windows/bits.zig

andrewrk · 2020-01-30T14:26:45Z

Nice work!

Add an advanced segfault handler on windows

3500b41

LemonBoy reviewed Jan 29, 2020

View reviewed changes

Changing stuff and seeing what happens

b7cd60a

Reorganize definitions

4a4d6f2

Fix off-by-one error

c0c9c60

Fix aarch64

b1884b3

andrewrk requested changes Jan 30, 2020

View reviewed changes

Rocknest added 2 commits January 30, 2020 08:53

Remove intCast's

94f29ae

Fix one more edge case

a5f18c2

andrewrk merged commit 0303e7b into ziglang:master Jan 30, 2020

Rocknest deleted the windows-traces branch January 30, 2020 15:17

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bring windows segfault handler on par with linux #4319

Bring windows segfault handler on par with linux #4319

Rocknest commented Jan 29, 2020

LemonBoy Jan 29, 2020

Rocknest Jan 29, 2020

LemonBoy Jan 29, 2020

Rocknest Jan 29, 2020

andrewrk Jan 29, 2020

LemonBoy Jan 29, 2020

andrewrk commented Jan 29, 2020

Rocknest commented Jan 29, 2020

andrewrk commented Jan 29, 2020

LemonBoy commented Jan 29, 2020

Rocknest commented Jan 29, 2020

LemonBoy commented Jan 29, 2020

Rocknest commented Jan 29, 2020 •

edited

Loading

LemonBoy commented Jan 29, 2020

andrewrk commented Jan 29, 2020

Rocknest commented Jan 29, 2020

andrewrk commented Jan 29, 2020

andrewrk Jan 30, 2020

Rocknest Jan 30, 2020

andrewrk Jan 30, 2020

Rocknest Jan 30, 2020

andrewrk commented Jan 30, 2020

Bring windows segfault handler on par with linux #4319

Bring windows segfault handler on par with linux #4319

Conversation

Rocknest commented Jan 29, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andrewrk commented Jan 29, 2020

Rocknest commented Jan 29, 2020

andrewrk commented Jan 29, 2020

LemonBoy commented Jan 29, 2020

Rocknest commented Jan 29, 2020

LemonBoy commented Jan 29, 2020

Rocknest commented Jan 29, 2020 • edited Loading

LemonBoy commented Jan 29, 2020

andrewrk commented Jan 29, 2020

Rocknest commented Jan 29, 2020

andrewrk commented Jan 29, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andrewrk commented Jan 30, 2020

Rocknest commented Jan 29, 2020 •

edited

Loading