Hello,
Some core dumps appear when an interface is removed in version 10.3.2 (BSD OS).
Attached back‑trace:
* thread #1, name = 'dhcpcd', stop reason = signal SIGSEGV
* frame #0: 0x00002fe09da3ea7e dhcpcd`inet_getroutes [inlined] inet_dhcproutes(routes=0x00002fe8be6c2d20, ifp=0x0000346e85a80c80, have_default=<unavailable>) at ipv4.c:303:31
frame #1: 0x00002fe09da3ea41 dhcpcd`inet_getroutes(ctx=0x00002fe8be6c3978, routes=0x00002fe8be6c2d20) at ipv4.c:497:7
frame #2: 0x00002fe09da2f1dd dhcpcd`rt_build(ctx=0x00002fe8be6c3978, af=2) at route.c:787:7
frame #3: 0x00002fe09da3f616 dhcpcd`ipv4_applyaddr(arg=0x0000346e85a80c80) at ipv4.c:769:5
frame #4: 0x00002fe09da3ac14 dhcpcd`dhcp_deconfigure(arg=0x0000346e85a80c80) at dhcp.c:2963:3
frame #5: 0x00002fe09da390e6 dhcpcd`dhcp_drop(ifp=<unavailable>, reason=<unavailable>) at dhcp.c:3049:2 [artificial]
frame #6: 0x00002fe09da3bd55 dhcpcd`dhcp_handleifa(cmd=13, ia=0x0000346e85a14500, pid=0) at dhcp.c:4461:4
frame #7: 0x00002fe09da3fa84 dhcpcd`ipv4_handleifa(ctx=0x00002fe8be6c3978, cmd=13, ifs=<unavailable>, ifname="vmx4", addr=0x00002fe8be6c3400, mask=0x00002fe8be6c2eb4, brd=0x00002fe8be6c2eb0, addrflags=0, pid=0) at ipv4.c:958:8
frame #8: 0x00002fe09da35c15 dhcpcd`if_handlelink [inlined] if_ifa(ctx=0x00002fe8be6c3978, ifam=0x00002fe8be6c2eb8) at if-bsd.c:1504:3
frame #9: 0x00002fe09da35bb2 dhcpcd`if_handlelink [inlined] if_dispatch(ctx=0x00002fe8be6c3978, rtm=0x00002fe8be6c2eb8) at if-bsd.c:1581:10
frame #10: 0x00002fe09da35991 dhcpcd`if_handlelink(ctx=0x00002fe8be6c3978) at if-bsd.c:1689:9
frame #11: 0x00002fe09da2337e dhcpcd`dhcpcd_handlelink(arg=0x00002fe8be6c3978, events=<unavailable>) at dhcpcd.c:1391:6
frame #12: 0x00002fe09da2533e dhcpcd`eloop_start [inlined] eloop_run_kqueue(eloop=0x0000346e85a52180, ts=<unavailable>) at eloop.c:922:3
frame #13: 0x00002fe09da25301 dhcpcd`eloop_start(eloop=0x0000346e85a52180) at eloop.c:1081:11
frame #14: 0x00002fe09da21bfa dhcpcd`main(argc=11, argv=0x00002fe8be6c4640, envp=0x00002fe8be6c46a0) at dhcpcd.c:3105:6
frame #15: 0x00002fe8c1c50120 libc.so.7`__libc_start1(argc=11, argv=0x00002fe8be6c4640, env=0x00002fe8be6c46a0, cleanup=<unavailable>, mainX=(dhcpcd`main at dhcpcd.c:2306)) at libc_start1.c:180:7
frame #16: 0x00002fe09da1c7c1 dhcpcd`_start at crt1_s.S:80
(We have added patches, so line numbers may no longer match.)
When we reach inet_getroutes we notice a few things:
state->addr = NULL and state->added = STATE_ADDED
The state->addr = NULL condition is what eventually triggers the crash.
In version 10.2.0 this problem did not occur because we used to check that :
state->state == DHS_BOUND.
(That check is no longer present in 10.3.2), and we reach this code path with state->state == DHS_NONE; that's why the crash was avoided before.
Fix that I applied locally
In ipv4_applyaddr there is an if (state->addr != NULL) block that calls ipv4_deladdr. And then inside ipv4_deladdr :
- state->addr pointer is set to NULL
- state->added is cleared (0).
I applied the same reasoning by adding the following code:
/* Someone might have deleted our address */
if (state->addr != NULL)
ipv4_deladdr(state->addr, 0);
/* remove added state because there is no address */
else
state->added = 0;
rt_build(ifp->ctx, AF_INET);
This appears to fix our issue.
Best regards,
Matthieu
Hello,
Some core dumps appear when an interface is removed in version 10.3.2 (BSD OS).
Attached back‑trace:
(We have added patches, so line numbers may no longer match.)
When we reach inet_getroutes we notice a few things:
state->addr = NULL and state->added = STATE_ADDED
The state->addr = NULL condition is what eventually triggers the crash.
In version 10.2.0 this problem did not occur because we used to check that :
state->state == DHS_BOUND.
(That check is no longer present in 10.3.2), and we reach this code path with state->state == DHS_NONE; that's why the crash was avoided before.
Fix that I applied locally
In ipv4_applyaddr there is an if (state->addr != NULL) block that calls ipv4_deladdr. And then inside ipv4_deladdr :
I applied the same reasoning by adding the following code:
This appears to fix our issue.
Best regards,
Matthieu