stack trace SEGV when linking libc and using debug_allocator within a thread

[blblack]

Zig Version

0.16.0-dev.46+d4df65e35

Steps to Reproduce and Observed Behavior

This is the simplest test code I got this down to:

const std = @import("std");

fn sub_thread() !void {
    var debug_allocator: std.heap.DebugAllocator(.{}) = .init;
    const alloc = debug_allocator.allocator();
    const thing: []u8 = try alloc.alloc(u8, 1);
    defer alloc.free(thing);
}

pub fn main() !void {
    const thr = try std.Thread.spawn(.{}, sub_thread, .{});
    thr.join();
}

For me, on x86_64 Linux, if I run the above via plain zig run it executes just fine. But zig run -lc (link libc, which means threads are pthreads) causes this sort of thing:

Segmentation fault at address 0xffffffffffffff40
/home/bblack/repos/zig/lib/std/debug.zig:953:52: 0x1081a04 in next_internal (std.zig)
        const new_fp = math.add(usize, @as(*usize, @ptrFromInt(fp)).*, fp_bias) catch
                                                   ^
/home/bblack/repos/zig/lib/std/debug.zig:876:39: 0x104cc66 in next (std.zig)
        var address = it.next_internal() orelse return null;
                                      ^
/home/bblack/repos/zig/lib/std/debug.zig:510:29: 0x113fbd2 in captureStackTrace (std.zig)
            addr.* = it.next() orelse {
                            ^
/home/bblack/repos/zig/lib/std/heap/debug_allocator.zig:515:40: 0x11401d4 in collectStackTrace (std.zig)
            std.debug.captureStackTrace(first_trace_addr, &stack_trace);
                                       ^
/home/bblack/repos/zig/lib/std/heap/debug_allocator.zig:333:34: 0x113caf0 in captureStackTrace (std.zig)
                collectStackTrace(ret_addr, stack_addresses);
                                 ^
/home/bblack/repos/zig/lib/std/heap/debug_allocator.zig:801:41: 0x113a356 in alloc (std.zig)
                bucket.captureStackTrace(ret_addr, slot_count, 0, .alloc);
                                        ^
/home/bblack/repos/zig/lib/std/mem/Allocator.zig:129:26: 0x10ba2ce in allocBytesWithAlignment__anon_14058 (std.zig)
    return a.vtable.alloc(a.ptr, len, alignment, ret_addr);
                         ^
/home/bblack/repos/zig/lib/std/mem/Allocator.zig:269:40: 0x1095789 in allocWithSizeAndAlignment__anon_10662 (std.zig)
    return self.allocBytesWithAlignment(alignment, byte_count, return_address);
                                       ^
/home/bblack/repos/zig/lib/std/mem/Allocator.zig:257:89: 0x10682bc in alloc__anon_5687 (std.zig)
    const ptr: [*]align(a.toByteUnits()) T = @ptrCast(try self.allocWithSizeAndAlignment(@sizeOf(T), a, n, return_address));
                                                                                        ^
/home/bblack/repos/gdnsd/direct.zig:6:40: 0x11373ac in sub_thread (direct.zig)
    const thing: []u8 = try alloc.alloc(u8, 1);
                                       ^
/home/bblack/repos/zig/lib/std/Thread.zig:529:21: 0x1137533 in callFn__anon_22584 (std.zig)
                    @call(.auto, f, args) catch |err| {
                    ^
/home/bblack/repos/zig/lib/std/Thread.zig:782:30: 0x1136e56 in entryFn (std.zig)
                return callFn(f, args_ptr.*);
                             ^
v./nptl/pthread_create.c:448:8: 0x7f1049559b7a in start_thread (pthread_create.c)
../sysdeps/unix/sysv/linux/x86_64/clone3.S:78:0: 0x7f10495d77b7 in __clone3 (../sysdeps/unix/sysv/linux/x86_64/clone3.S)
???:?:?: 0x0 in ??? (???)
Aborted

Note this is an extremely similar trace to #24970 , but that is flagged as ppc-only. This happens on x86_64 Linux, when linking libc and spinning up a debug allocator inside a thread.

Also note: this problem goes away if I revert the deletion of MemoryAccessor and related followup commits.

Expected Behavior

Not crashing

[rootbeer]

I'm still hitting this SEGV. This failure triggers during local runs of the the Zig precheckin tests for me (the Thread spawn test cases use the DebugAllocator on a secondary thread, like in #24970 (comment)).

I'm not sure why this isn't failing in CI, so there must be some local difference on my machine? (I'm on x86_64 linux.)

I have a slightly narrower test case (no DebugAllocator, just direct calls to std.debug.captureStackTrace):

const std = @import("std");

pub fn captureTrace() void {
    var addrs:[32]usize = @splat(0);
    var stack: std.builtin.StackTrace = .{
        .index = 0,
        .instruction_addresses = &addrs,
    };
    std.debug.captureStackTrace(@returnAddress(), &stack);
}

pub fn main() !void {
    captureTrace();
    std.debug.print("Done direct\n", .{});

    const th = try std.Thread.spawn(.{}, captureTrace, .{});
    th.join();
    std.debug.print("Done via thread\n", .{});
}

Works with zig run, crashes with zig run -lc, works with zig run -target native-native-musl -lc, so its likely glibc.

Seems very similar to #24970, and this is a system glibc without frame pointers. But that bug is marked fixed... I'm running glibc v2.41 on kernel v6.14.4

The fault for this test case is consistent for me: Segmentation fault at address 0xffffffffffffff40.

My Zig tree is a three days old (it definitely contains #25048 - std.debug: remove @frameAddress() "UAF").

$ zig version
0.16.0-dev.209+426d65d70

[mlugg]

I'm still hitting this SEGV

Yes, this issue is not yet fixed---that's why it's open. I'm just finishing up work on branch which will solve this; hang in there for a couple more days.

[blblack]

In the meantime, if this is messing with your normal application code builds in debug mode via the debug allocator's tracing, just change your DebugAllocator options for now to use: std.heap.DebugAllocator(.{ .stack_trace_frames = 0 })