Compiler crash: runtime-conditional break/return inside inline loop

[CurtisFenner]

I'm building using zig 0.4.0+fcc0728 on 64 bit Windows 10, built from source in Release mode.

The following file run through zig test causes Zig to exit with no output and only empty files written to the zig-cache:

fn crash() !void {
    return error.Crash;
}

test "A problem happens" {
    inline for ([_]u8{ 0, 1 }) |x| {
        if (crash()) {} else |z| {
            return;
        }
    }
}

The exit code, according to an echo %errorlevel%, is -1073741819. The Windows Event Viewer has the following log:

Exception code: 0xc0000005
Fault offset: 0x0000000001d20690
Faulting process id: 0xac8

The test input is seemingly minimal. It doesn't crash with only one/zero elements, it doesn't crash if the return is removed, replaced with other code, or moved to the other branch (though break also causes it). It doesn't crash with a regular if/else. It doesn't crash if replaced with try or with catch.

[SamTebbs33]

I can't run this one windows but on Linux I get

Program received signal SIGSEGV, Segmentation fault.
0x000055555a509e30 in llvm::BasicBlock::getContext() const ()
(gdb) bt
#0  0x000055555a509e30 in llvm::BasicBlock::getContext() const ()
#1  0x000055555a5a2439 in llvm::BranchInst::BranchInst(llvm::BasicBlock*, llvm::BasicBlock*, llvm::Value*, llvm::Instruction*) ()
#2  0x000055555a537408 in LLVMBuildCondBr ()
#3  0x000055555645943b in ir_render_cond_br (g=0x55555c5ff840, executable=0x55555c65cfb8, cond_br_instruction=0x55555c87dc80) at /home/sam/repos/zig/src/codegen.cpp:3281
#4  0x0000555556463122 in ir_render_instruction (g=0x55555c5ff840, executable=0x55555c65cfb8, instruction=0x55555c87dc80) at /home/sam/repos/zig/src/codegen.cpp:5631
#5  0x0000555556463b43 in ir_render (g=0x55555c5ff840, fn_entry=0x55555c65ce60) at /home/sam/repos/zig/src/codegen.cpp:5813
#6  0x0000555556468f55 in do_code_gen (g=0x55555c5ff840) at /home/sam/repos/zig/src/codegen.cpp:7027
#7  0x00005555564723b0 in codegen_build_and_link (g=0x55555c5ff840) at /home/sam/repos/zig/src/codegen.cpp:9615
#8  0x000055555644a91a in main (argc=3, argv=0x7fffffffe868) at /home/sam/repos/zig/src/main.cpp:1190

[CurtisFenner]

Thanks for confirming it's not Windows specific!

[ntgraff]

I am having this same issue in the following code snippet, so I'm leaving it here to see if it is useful at all. The backtrace is basically the same.

// T is any type
const info = switch (@typeInfo(T)) {
    .Struct => |i| i,
    else => @compileError("not a struct"),
};

// json is std.json.ValueTree
const json_object = switch (json.root) {
    .Object => |o| o,
    else => return error.JsonNotObject,
};

inline for (info.fields) |field| {
    // This if causes the segfault when `T` has more than one field,
    // but works when there is one field, or if the else branch does not have a return
    const field_value = if (json_object.getValue(field.name)) |value| value else {
        return error.JsonMissingField;
    };
}

It seems that this happens when there is a chance of an early return within an inline for, probably related (or the same issue) as #2908.

zig version is 0.4.0+ceec2393c

[CurtisFenner]

This also appears to happen with a regular non-error switch:

const ResultType = union(enum) {
    Alpha: u32,
    Beta: u32,
};

test "foo" {
    inline for ([2]u32{ 1, 7 }) |field| {
        var result = ResultType{ .Alpha = 7 };
        switch (result) {
            .Alpha => {},
            .Beta => {},
        }
    }
}

zig version 0.4.0+9a18db8

[CurtisFenner]

Interestingly, adding an else unreachable in a regular if also causes a crash:

const ResultType = struct {
    tag: u2,
    Alpha: u32,
    Beta: u32,
};

test "foo" {
    inline for ([2]u32{ 1, 7 }) |field| {
        var result = ResultType{ .tag = 1, .Alpha = 7, .Beta = undefined };
        if (result.tag == 1) {} else unreachable;
    }
}

so perhaps this has something to do with the 'exhaustiveness' of these ifs.

[pixelherodev]

I haven't done any real work on the compiler, but would be more than willing to set aside time to look into this.

Any tips on how to get started looking into a bug like this?

[andrewrk]

@pixelherodev this might a particularly difficult bug to start with as a contributor.

Here's where we are collecting tips on how to do stage1 ir.cpp work: https://github.com/ziglang/zig/wiki/FAQ#are-there-any-good-examples-of-advanced-internals-development-with-zig-specifically-stage1-bug-fixes

You might look for label:"contributor friendly" label:stage1 for starters.

---

Confirmed that this is still an issue in master branch.