Zig Version
0.14.0-dev.1646+b19d0fb0f
Steps to Reproduce and Observed Behavior
I observed this error twice today during some development. Judging by the stack trace, it must be some sort of transient DNS failure that triggers it. I couldn't find other open bugs related to Dns or linuxLookupName. The issue immediately resolved itself during the next attempt, but then later in the day failed again with the identical panic.
Possibly relevant: the tool that invokes http.Client uses a std.Thread.Pool and each download is spawned using a WaitGroup and pool.spawnWg. I've run this dozens of times in the past few weeks without issue so I think my code is correct.
thread 127678 panic: integer overflow
/nix/store/j766aq6arpzdrj9hd86ml7lncxggr7rl-zig-0.14.0-dev.1646+b19d0fb0f/lib/std/net.zig:1657:22: 0x1322961 in resMSendRc (fetch-assets)
outer: while (t2 - t0 < timeout) : (t2 = @as(u64, @bitCast(std.time.milliTimestamp()))) {
^
/nix/store/j766aq6arpzdrj9hd86ml7lncxggr7rl-zig-0.14.0-dev.1646+b19d0fb0f/lib/std/net.zig:1466:19: 0x1326e48 in linuxLookupNameFromDns (fetch-assets)
try resMSendRc(qp[0..nq], ap[0..nq], apbuf[0..nq], rc);
^
/nix/store/j766aq6arpzdrj9hd86ml7lncxggr7rl-zig-0.14.0-dev.1646+b19d0fb0f/lib/std/net.zig:1418:34: 0x1328318 in linuxLookupNameFromDnsSearch (fetch-assets)
return linuxLookupNameFromDns(addrs, canon, name, family, rc, port);
^
/nix/store/j766aq6arpzdrj9hd86ml7lncxggr7rl-zig-0.14.0-dev.1646+b19d0fb0f/lib/std/net.zig:1057:49: 0x1328fbb in linuxLookupName (fetch-assets)
try linuxLookupNameFromDnsSearch(addrs, canon, name, family, port);
^
/nix/store/j766aq6arpzdrj9hd86ml7lncxggr7rl-zig-0.14.0-dev.1646+b19d0fb0f/lib/std/net.zig:994:28: 0x12c4a95 in getAddressList (fetch-assets)
try linuxLookupName(&lookup_addrs, &canon, name, family, .{ .NUMERICSERV = true }, port);
^
/nix/store/j766aq6arpzdrj9hd86ml7lncxggr7rl-zig-0.14.0-dev.1646+b19d0fb0f/lib/std/net.zig:776:36: 0x11ce920 in tcpConnectToHost (fetch-assets)
const list = try getAddressList(allocator, name, port);
^
/nix/store/j766aq6arpzdrj9hd86ml7lncxggr7rl-zig-0.14.0-dev.1646+b19d0fb0f/lib/std/http/Client.zig:1328:40: 0x11a9ca5 in connectTcp (fetch-assets)
const stream = net.tcpConnectToHost(client.allocator, host, port) catch |err| switch (err) {
^
/nix/store/j766aq6arpzdrj9hd86ml7lncxggr7rl-zig-0.14.0-dev.1646+b19d0fb0f/lib/std/http/Client.zig:1492:38: 0x117e44e in connect (fetch-assets)
} orelse return client.connectTcp(host, port, protocol);
^
/nix/store/j766aq6arpzdrj9hd86ml7lncxggr7rl-zig-0.14.0-dev.1646+b19d0fb0f/lib/std/http/Client.zig:1640:27: 0x114a220 in open (fetch-assets)
try client.connect(valid_uri.host.?.raw, uriPort(valid_uri, protocol), protocol);
^
/home/mo/.cache/zig/p/1220ab79b57a73d34b16b2264a3f3326e24b02966e4eefd7ef3961b3f4256d285949/src/common/src/download.zig:42:30: 0x1149389 in downloadFile (fetch-assets)
var req = try client.open(.GET, uri, .{
Expected Behavior
A DNS failure or network failure should not trigger an integer overflow panic. Instead, an appropriate error should be returned.
Zig Version
0.14.0-dev.1646+b19d0fb0f
Steps to Reproduce and Observed Behavior
I observed this error twice today during some development. Judging by the stack trace, it must be some sort of transient DNS failure that triggers it. I couldn't find other open bugs related to Dns or linuxLookupName. The issue immediately resolved itself during the next attempt, but then later in the day failed again with the identical panic.
Possibly relevant: the tool that invokes http.Client uses a std.Thread.Pool and each download is spawned using a WaitGroup and pool.spawnWg. I've run this dozens of times in the past few weeks without issue so I think my code is correct.
Expected Behavior
A DNS failure or network failure should not trigger an integer overflow panic. Instead, an appropriate error should be returned.