MacOS address in use not handled gracefully
I happened to have an asn.pl
active on one interface and that triggered an assertion due to mismatching result values.
(lldb) print sock->children[0].result
(isc_result_t) $11 = ISC_R_ADDRINUSE
(lldb) print sock->children[1].result
(isc_result_t) $12 = ISC_R_SUCCESS
(lldb) print sock->children[2].result
(isc_result_t) $13 = ISC_R_SUCCESS
(lldb) print sock->children[3].result
(isc_result_t) $14 = ISC_R_SUCCESS
(lldb) print sock->children[4].result
(isc_result_t) $15 = ISC_R_SUCCESS
* thread #1, stop reason = signal SIGSTOP
frame #0: 0x00000001814b8e28 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x00000001814eb43c libsystem_pthread.dylib`pthread_kill + 292
frame #2: 0x0000000181433454 libsystem_c.dylib`abort + 124
frame #3: 0x0000000102f6a478 named`assertion_failed(file="netmgr/udp.c", line=181, type=isc_assertiontype_insist, cond="result == sock->children[i].result") at main.c:236:3
frame #4: 0x000000010351a14c libisc-9.19.10-dev.dylib`isc_assertion_failed(file="netmgr/udp.c", line=181, type=isc_assertiontype_insist, cond="result == sock->children[i].result") at assertions.c:49:2
* frame #5: 0x0000000103517050 libisc-9.19.10-dev.dylib`isc_nm_listenudp(mgr=0x0000000106a781e0, workers=8, iface=0x00000001088eedd8, cb=(libns-9.19.10-dev.dylib`ns__client_request at client.c:1689), cbarg=0x00000001088eed80, sockp=0x00000001088eee98) at udp.c:181:3
frame #6: 0x00000001033185a4 libns-9.19.10-dev.dylib`ns_interface_listenudp(ifp=0x00000001088eed80) at interfacemgr.c:494:11
frame #7: 0x000000010331763c libns-9.19.10-dev.dylib`interface_setup(mgr=0x0000000106a121a0, addr=0x000000016cea2670, name="lo0", ifpret=0x000000016cea2638, elt=0x00000001067f0bf0, addr_in_use=0x000000016cea25ff) at interfacemgr.c:696:11
frame #8: 0x0000000103315ed0 libns-9.19.10-dev.dylib`do_scan(mgr=0x0000000106a121a0, verbose=true, config=true) at interfacemgr.c:1266:13
frame #9: 0x00000001033157b0 libns-9.19.10-dev.dylib`ns_interfacemgr_scan(mgr=0x0000000106a121a0, verbose=true, config=true) at interfacemgr.c:1326:11
frame #10: 0x0000000102f80860 named`load_configuration(filename="/dev/null", server=0x0000000106b3c8c0, first_time=true) at server.c:8947:12
frame #11: 0x0000000102f7ed18 named`run_server(task=0x0000000106ac6640, event=0x0000000000000000) at server.c:9974:2
frame #12: 0x000000010354ffb4 libisc-9.19.10-dev.dylib`task_run(task=0x0000000106ac6640) at task.c:470:4
frame #13: 0x000000010354fb98 libisc-9.19.10-dev.dylib`task__run(arg=0x0000000106ac6640) at task.c:287:24
frame #14: 0x000000010352aa70 libisc-9.19.10-dev.dylib`isc__job_cb(idle=0x0000000106ac6a08) at job.c:75:2
frame #15: 0x00000001041dafe4 libuv.1.dylib`uv__run_idle + 152
frame #16: 0x00000001041d5cd0 libuv.1.dylib`uv_run + 204
frame #17: 0x0000000103535bb8 libisc-9.19.10-dev.dylib`loop_run(loop=0x0000000106c3c000) at loop.c:270:6
frame #18: 0x00000001035342bc libisc-9.19.10-dev.dylib`loop_thread(arg=0x0000000106c3c000) at loop.c:297:2
frame #19: 0x0000000103534174 libisc-9.19.10-dev.dylib`isc_loopmgr_run(loopmgr=0x00000001067ef750) at loop.c:481:2
frame #20: 0x0000000102f6a17c named`main(argc=6, argv=0x000000016cea36c0) at main.c:1513:2
frame #21: 0x0000000181509430 libdyld.dylib`start + 4
The assertion doesn't make sense on the Mac as mgr->load_balance_sockets
is false
and fd
is the result of dup
rather than using socket
and bind
resulting in different result
values being stored.