-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
segfault running "zig build" when zig is built in debug mode #10719
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
A workaround for issue ziglang#10719. Moves the expression `std.time.epoch.windows * (std.time.ns_per_s / 100)` into a global const to force compiler to evaluate it a comptime (even in debug builds). Evaluating it at comptime causes a segfault on my Windows system. See issue ziglang#10719 for more details.
A workaround for issue ziglang#10719. Moves the expression `std.time.epoch.windows * (std.time.ns_per_s / 100)` into a global const to force compiler to evaluate it a comptime (even in debug builds) because evaluating it at runtime causes a segfault on my Windows system. See issue ziglang#10719 for more details.
A workaround for issue ziglang#10719. Moves the expression `std.time.epoch.windows * (std.time.ns_per_s / 100)` into a global const to force compiler to evaluate it a comptime (even in debug builds) because evaluating it at runtime causes a segfault on my Windows system. See issue ziglang#10719 for more details.
A workaround for issue ziglang#10719. Moves the expression `std.time.epoch.windows * (std.time.ns_per_s / 100)` into a global const to force compiler to evaluate it a comptime (even in debug builds) because evaluating it at runtime causes a segfault on my Windows system. I also needed to remove the temporary `adjusted_epoc` variable. See issue ziglang#10719 for more details.
A workaround for issue ziglang#10719. Removes the temporary i128 local variable `adjusted_epoch` which prevents the segfault from occuring. It's unclear as to why. See issue ziglang#10719 for more details.
A workaround for issue ziglang#10719. Removes the temporary i128 local variable `adjusted_epoch` which prevents the segfault from occuring. It's unclear as to why. See issue ziglang#10719 for more details.
A workaround for issue ziglang#10719. Removes the temporary i128 local variable `adjusted_epoch` which prevents the segfault from occuring. It's unclear as to why. See issue ziglang#10719 for more details.
A workaround for issue ziglang#10719. Removes the temporary i128 local variable `adjusted_epoch` which prevents the segfault from occuring. It's unclear as to why. See issue ziglang#10719 for more details.
For convenience I've attached a diff between the crashing version (with the |
This comment has been minimized.
This comment has been minimized.
Ok I found a way to reproduce this issue. Here's the program:
extern fn __muloti4(a: i128, b: i128, overflow: *c_int) callconv(.C) i128;
pub fn main() void {
var overflow: c_int = -1;
var result = __muloti4(132879187288034414, -116444736000000000, &overflow);
@import("std").log.info("result={}, overflow={}", .{result, overflow});
} Works when you compile/run it like this: >zig build-exe bug.zig
>bug
info: result=-15473081883649723297144704000000000, overflow=0 Add >zig build-exe bug.zig -lc++
>bug
Segmentation fault at address 0xffffffffffffffff In the first case, zig links to |
fixes ziglang#10719 compiler_rt already provides __muloti4 but libc++ is also providing it and when linking libc++ it causes a crash on my windows x86_64 machine.
fixes #10719 compiler_rt already provides __muloti4 but libc++ is also providing it and when linking libc++ it causes a crash on my windows x86_64 machine.
fixes #10719 compiler_rt already provides __muloti4 but libc++ is also providing it and when linking libc++ it causes a crash on my windows x86_64 machine.
Uh oh!
There was an error while loading. Please reload this page.
Zig Version
0.10.0-dev.5230+4613499fa
Steps to Reproduce
Build a debug version of Zig on Windows. Run it with "zig build".
Expected Behavior
Not to crash
Actual Behavior
Crashes with:
Using a debugger I can see the crash occurs in
__muloti4
. This is normally provided bycompiler_rt
, however, in the Zig executable it's shadowed by the one fromc++.lib
. I can reproduce this by compiling a simple test program and adding-lc++
which will cause it to link to__muloti4
fromc++lib
and reproduce the crash.Note that this call to
__muloti4
comes fromstd.os.windows.fromSysTime
.If I remove the
adjusted_epoch
local variable, the call to_muloti4
goes away and so does the crash. I've included the assembly for both of these functions below.The segfault occurs early in
__muloti4
which makes me guess the segfault probably occurs here:zig/lib/std/special/compiler_rt/mulo.zig
Line 21 in aca665c
My guess is that zig isn't able to handle a
callconv (.C)
function with 2i128
followed by a pointer, and the pointer ends up being invalid. Note that this is just "integers" and "pointers" which #1481 says it supports, but this might be a regression of it.Supplemental Info
Not sure if this helps but here are the values of each variable in
fromSysTime
if that helps.hns
(from debugger)132879187288034414
std.time.epoch.windows * (std.time.ns_per_s / 100)
(calculated by hand, these are comptime-known)-116444736000000000
adjusted_epoch
16434451288034414
1643445128803441400
Also for reference, here's the assembly for
fromSysTime
:The text was updated successfully, but these errors were encountered: