radvd encounters segmentation fault on boot #174
Comments
|
On Tue, Mar 01, 2022 at 11:19:36PM -0800, John Kisch wrote:
I'm having an issue where the radvd daemon encounters a segmentation
fault when the daemon is started at boot time. The system with this
issue is running Alpine Linux 3.15
Alpine Linux uses the OpenRC init system.
After the system is finished booting, `rc-service radvd stop; rc-service
radvd` start results in the daemon starting successfully. Perhaps the
radvd daemon is being started before the eth1 device is up? This would
make sense as to why the daemon starts successfully after the system
finishes coming up.
I've also opened an issue with the folks at Alpine Linux, as seen here:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/13570
Please let me know if there's any further information that I can
provide.
See if the OpenRC init system has something like
start this proces after the network interfaces are up
Groeten
Geert Stappers
--
Silence is hard to parse
|
OpenRC has a parameter that can be set in I still receive a segfault for radvd on boot with this set in /etc/rc.conf. |
|
|
Hi Robin, Whoops, missed that! This is radvd version 2.19. I'm using I'll go ahead and give building directly from the repo a shot here and post an update once I do so. Thanks! |
|
@johnkisch did the latest version work for you? |
|
my alpine box has same problem. my config is: --------- /etc/network/interfaces-------- auto lo allow-hotplug wan0 auto ppp0 auto br0 iface fib0 inet manual ------------------ /etc/radvd.conf --------- ---- and the folloing is dmsg |
|
just now, it crashed againt. i found these in dmesg it seems that radvd will crash when i change the bridge setting |
|
I'd say it's more general and it crashes whenever there is a change in network interfaces (adding, removing, changing settings...). One time I was removing some interfaces on the side, doing nothing to our bridges and yet, radvd still crashed. |
|
In my case, Alpine Linux v3.15 with radvd version 2.19. |
|
Running with master seems to handle things fine. Also 2.19 compiled from source crashes, too. Debug levels 2 and above trigger the crash. This is the minimal file that triggers the crash: |
|
@PaulosV thanks for that. I don't see why that config should crash on v2.19 and not in the latest master. Most of the changes in there were build systems or new features. If you use a dummy interface on Alpine, does it also crash, or is it some interaction between If you can spare the time to run Mostly I think this builds confidence to say we're good to have a v2.20 release soon. |
me 2. |
|
@robbat2 I'll try to do the bisect later. I'm not very comfortable in gdb but I can probably do a core dump or extract some vars/registers if needed. I'll also try the dummy interfaces. Also, I should have probably been clearer - when running in the foreground with high enough debug level (-d2 or -d3), radvd did not need any further convincing and crashed (SIGSEGV) instantly during startup. |
|
@PaulosV
#!/bin/sh
exe=$1
core=$2
gdb ${exe} \
--core ${core} \
--batch \
--quiet \
-ex "thread apply all bt full" \
-ex "quit"tee the output to a file, and it'll be good enough. |
|
Ok, so the issue was fixed by commit 06689f8 (issue #158, PR #161). The backtrace from tag v2.19: radvd-bt-2.19.log |
|
Apologies for not getting back to this - life got in the way, etc. I cloned latest on April 11th and rolled it into an apk package and installed. After giving a week of bake time, |
|
That is good to hear. I think, because the issue has quite a big impact and makes radvd downright unusable in some circumstances, it might make sense to backport that specific patch (06689f8) for Alpine and include it in the aports, so they can rebuild the package with the fix. |
|
Here's the MR in the aports repo for this: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33358 |
|
Did see https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33358/diffs and does understand the please do more as just git releases. |
|
@johnkisch can you please confirm 2.20 rc resolves the issue for you? |
|
On Wed, Dec 06, 2023 at 10:53:56PM -0800, Robin H. Johnson wrote:
@johnkisch can you please confirm 2.20 rc resolves the issue for you?
|
@stappersg I cannot reproduce the segfault in 2.20 RC. In 2.19 I can. I had to test with a Docker container, but since the same fix was applied in Alpine (by a patch) and it fixed it for me, I would say that it is fixed. |
Thanks for reporting. |
Hello,
I'm having an issue where the radvd daemon (version 2.19) encounters a segmentation fault when the daemon is started at boot time.
The system with this issue is running Alpine Linux 3.15:
NOTE: Alpine Linux is based on the musl C Standard Library. Alpine Linux uses the OpenRC init system.
I was able to capture a coredump, the backtrace reads as follows:
After the system is finished booting,
rc-service radvd stop; rc-service radvdstart results in the daemon starting successfully. Perhaps the radvd daemon is being started before the eth1 device is up? This would make sense as to why the daemon starts successfully after the system finishes coming up.I've also opened an issue with the folks at Alpine Linux, as seen here:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/13570
Please let me know if there's any further information that I can provide.
Thanks.
The text was updated successfully, but these errors were encountered: