zig build fails with SIGSEGV when fetching dependencies #35371

Zig Version

0.17.0-dev.313+27be3b069

Steps to Reproduce and Observed Behavior

Using zig on Ubuntu 25.10

Trying to build zls, I get fish: Job 1, 'zig build' terminated by signal SIGSEGV (Address boundary error). In the zls discord we worked out that this behavior occurred trying to fetch dependencies. By commenting out all dependencies in build.zig.zon building was able to proceed (albeit failing because no deps). I tried commenting out each dependency individually, however, I could only get some output when all dependencies were commented out. Building a new project created with zig init worked just fine.

Expected Behavior

Zig would fetch the needed dependencies before building

Are you able to build a debug compiler so that we can get a stack trace?

Sure, I think I correctly built the compiler, but now I'm not seeing the same segfault, I get a different failure:

Compiler crash context:
(no context)
thread 172686 panic: index out of bounds: index 371, len 255
/home/borpht/zig/lib/std/Io/net/HostName.zig:465:45: 0x5c21860 in parse (std.zig)
 @memcpy(rc.search_buffer[0..rest.len], rest);
 ^
/home/borpht/zig/lib/std/Io/net/HostName.zig:425:14: 0x5c224c5 in init (std.zig)
 parse(&rc, io, &file_reader.interface) catch |err| switch (err) {
 ^
/home/borpht/zig/lib/std/Io/Threaded.zig:14419:40: 0x5c22f7e in lookupDnsSearch (std.zig)
 const rc = HostName.ResolvConf.init(t_io) catch return error.ResolvConfParseFailed;
 ^
/home/borpht/zig/lib/std/Io/Threaded.zig:13699:58: 0x5c20063 in netLookupFallible (std.zig)
 if (native_os == .linux) return t.lookupDnsSearch(host_name, resolved, options);
 ^
/home/borpht/zig/lib/std/Io/Threaded.zig:13610:24: 0x5c1e160 in netLookup (std.zig)
 t.netLookupFallible(host_name, resolved, options) catch |err| switch (err) {
 ^
/home/borpht/zig/lib/std/Io/net/HostName.zig:169:31: 0x62b4db2 in lookup (std.zig)
 return io.vtable.netLookup(io.userdata, host_name, resolved, options);
 ^
/home/borpht/zig/lib/std/Io.zig:2410:13: 0x62b4c19 in start (std.zig)
 result_casted.* = @call(.auto, function, args_casted.*);
 ^
/home/borpht/zig/lib/std/Io/Threaded.zig:741:20: 0x5c9af1e in start (std.zig)
 future.func(future.contextPointer(), future.resultPointer());
 ^
/home/borpht/zig/lib/std/Io/Threaded.zig:1797:29: 0x5c96d93 in worker (std.zig)
 runnable.startFn(runnable, &thread, t);
 ^
/home/borpht/zig/lib/std/Thread.zig:422:13: 0x5c96945 in callFn__anon_27332 (std.zig)
 @call(.auto, f, args);
 ^
/home/borpht/zig/lib/std/Thread.zig:755:30: 0x5c96739 in entryFn (std.zig)
 return callFn(f, args_ptr.*);
 ^
???:?:?: 0x7120c52a3d63 in ??? (/lib/x86_64-linux-gnu/libc.so.6)
???:?:?: 0x7120c53373fb in ??? (/lib/x86_64-linux-gnu/libc.so.6)
Compiler crash context:
(no context)
Compiler crash context:
(no context)
fish: Job 1, '../zig/build/stage3/bin/zig bui...' terminated by signal SIGABRT (Abort)

FWIW this was a fresh build of Zig, commit sha: 3a6ddce4cf303d7a2bb618223043898d7b1bcc49

Thank you for the stack trace! The bug is now obvious. If you don't mind sharing your /etc/resolv.conf contents, that would also be interesting.

Sure thing!

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 10.255.255.254
search tail52758.ts.net staging.us-west-2.aws.appcues.net us-west-2.rds.amazonaws.com staging.us-west-2.data.aws.appcues.net prod.us-west-2.data.aws.appcues.net prod.us-west-2.aws.appcues.net preview.prod.us-west-2.aws.appcues.net us-west-2.aws.private.confluent.cloud prod.eu-central-1.data.aws.appcues.net prod.eu-central-1.aws.appcues.net eu-central-1.rds.amazonaws.com local

@andrewrk I can see you've self assigned, but I'd love to give this a crack as a first contribution if that's alright?

After looking into this a bit, it seems as though the line length and number of domains was once limited but that is not necessarily the case anymore? (also here: https://blogs.reliablepenguin.com/2025/11/28/understanding-etc-resolv-conf-purpose-history-and-common-uses: "Older glibc versions limit you to six domains and 256 characters total in the search list; newer ones lift that limit, but keeping it short is still good practice."). Not 100% on the reliability of this information, but it does appear that the limit has been lifted, at the very least varying between linux and windows.

edited: authoritative source confirming

In glibc 2.25 and earlier, the search list is limited to
six domains with a total of 256 characters. Since glibc
2.26, the search list is unlimited.

Would a fair path forward for this then, be to allow arbitrary line lengths? I'm not exactly sure what the downstream consequences of that might be if that's taken to the extreme though, so perhaps a much higher upper limit with graceful handling if that's exceeded could also be an option?

Keen for some thoughts :) Apologies if any of this is obvious