#SIGSEGV: address not mapped to object (fault address=0x0)

1 messages · Page 1 of 1 (latest)

mortal grotto
#

hey, trying to build a C project in zig. it builds fine but it doesnt seem to link it to the tests?

const std = @import("std");

pub fn build(b: *std.Build) void {
    const target = b.standardTargetOptions(.{});
    const optimize = b.standardOptimizeOption(.{});

    const upstream = b.dependency("upstream", .{});

    const lib_mod = b.createModule(.{
        .target = target,
        .optimize = optimize,
        .link_libc = true,
        .strip = false,
    });

    lib_mod.addCSourceFile(.{
        .file = upstream.path("src/yyjson.c"),
        .flags = &.{
            "-std=c99",
        },
    });
    lib_mod.addIncludePath(upstream.path("src"));
    const lib = b.addLibrary(.{
        .linkage = .static,
        .name = "yyjson",
        .root_module = lib_mod,
    });
    lib.installHeader(upstream.path("src/yyjson.h"), "yyjson.h");
    b.installArtifact(lib);

    const tests_mod = b.createModule(.{
        .root_source_file = b.path("tests.zig"),
        .target = target,
        .optimize = optimize,
        .link_libc = true,
    });
    tests_mod.addIncludePath(upstream.path("src"));
    tests_mod.linkLibrary(lib);

    const unit_tests = b.addTest(.{
        .root_module = tests_mod,
    });

    const run_unit_tests = b.addRunArtifact(unit_tests);
    const test_step = b.step("test", "run tests");
    test_step.dependOn(&run_unit_tests.step);
}

am i doing something stupid?

#

lldb:

Process 1530198 launched: '/.zig-cache/o/ab6efdacfc93ad450c40fae702f2b73c/test' (x86_64)
Process 1530198 stopped
* thread #1, name = 'test', stop reason = signal SIGSEGV: address not mapped to object (fault address=0x0)
    frame #0: 0x0000000000000000
error: memory read failed for 0x0
mortal grotto
#

Note this is 0.16, should be master branch from today, if not, from yesterday, I checked but there have been no changes in the mean time that may affect this anyways

ruby salmon
#

have you tried forcing llvm, (if that is relevent to your system), or different optimise modes?

#

if possible different targets would also be useful for hunting down/creating an issue

mortal grotto
#

i tried forcing llvm for the library module, but to no avail, just tried forcing llvm for the test too, which instead brought up a test runner segfault

#

posting here too (mostly so i have a backup of it just in case 😆 )

* thread #1, name = 'test', stop reason = signal SIGSEGV: invalid permissions for mapped object (fault address=0x1014368)
    frame #0: 0x0000000001014368 test`builtin.zig_backend
test`builtin.zig_backend:
->  0x1014368 <+0>: addb   (%rax), %al
    0x101436a <+2>: addb   %al, (%rax)
    0x101436c <+4>: addb   %al, (%rax)
    0x101436e <+6>: addb   %al, (%rax)
(lldb) bt
* thread #1, name = 'test', stop reason = signal SIGSEGV: invalid permissions for mapped object (fault address=0x1014368)
  * frame #0: 0x0000000001014368 test`builtin.zig_backend
    frame #1: 0x000000000118e925 test`test_runner.mainTerminal(init=<unavailable>) at test_runner.zig:291:25
    frame #2: 0x000000000118e287 test`test_runner.main(init=process.Init.Minimal @ 0x00007fffffffac48) at test_runner.zig:73:28
    frame #3: 0x000000000118bbc9 test`start.callMain at start.zig:686:88
    frame #4: 0x000000000118bb46 test`start.callMainWithArgs at start.zig:637:20
    frame #5: 0x000000000118bafb test`start.main(c_argc=1, c_argv=0x00007fffffffae98, c_envp=0x00007fffffffaea8) at start.zig:662:28
    frame #6: 0x00007ffff7c2a4d8 libc.so.6`__libc_start_call_main + 120
    frame #7: 0x00007ffff7c2a59b libc.so.6`__libc_start_main@@GLIBC_2.34 + 139
    frame #8: 0x00000000010436a5 test`_start + 37
ruby salmon
#

ah, since its c, it will be always be clang facepalm

mortal grotto
ruby salmon
#

compiling c always does llvm currently
arocc is a long way off

mortal grotto
#

oh fair

#

😆

#

might be worth going on the issue tracker?

ruby salmon
#

ye, probably wont get much help here for a while

mortal grotto
#

Yeah unfortunate timing

mortal grotto
#

yeah i can confirm this does not occur on 0.15