Need help diagnosing libdnet segfault

[clickworkorange]

I've built an application that includes libdnet from source, which segfaults when calling libdnet's intf_loop method. The developers of that application say they are unable to help since I'm not running their precompiled binary, and I'm out of my depth trying to figure out what the cause might be on my own. I think intf_loop uses procfs /proc/net/dev and this looks ok on my system:

$ less ~/Sources/OpenCPN-Release_5.10.0/build/libs/libdnet/config.h | grep -b1 HAVE_LINUX_PROCFS
2124-/* Define if you have the [Linux](https://www.cruisersforum.com/forums/tags/linux.html) /proc filesystem. */
2177:#define HAVE_LINUX_PROCFS

$ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  eth0:  216800    2749    0    0    0     0          0         0   871666    2120    0    0    0     0       0          0

The relevant application's included copy of libdnet can be found here: https://github.com/OpenCPN/OpenCPN/tree/ad639f6a5940e98bed3ffd1609b00d3cbd1729e1/libs/libdnet/libdnet-libdnet-1.18.0

I understand if you can't help either, but thought I'd check - perhaps the issue sounds familiar to someone?

[ofalk]

Hey! Let me clarify a few things:

• Does the precompiled binary work for you?
• Can you run the application under strace and provide me the output?
• Is OpenCPN using any specific compile options?
• What Linux distribution are you using?
• I confirm the output of your /proc/net/dev doesn't look suspicious
• I haven't touched that particular function recently - actually never, since I took over the maintainership

[clickworkorange]

Hi @ofalk, thanks for taking the time to respond! You actually immediately led me to the answer - it's been over a decade since I last used strace and I have to admit I'd forgotten it even existed. But, attaching it to the PID of OpenCPN, it seems obvious what's going on: I have turned off IPv6 and libdnet doesn't like it:

socket(AF_INET, SOCK_DGRAM, IPPROTO_IP) = 33
setsockopt(33, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = -1 EAFNOSUPPORT (Address family not supported by protocol)
close(33)                               = 0
openat(AT_FDCWD, "/proc/net/dev", O_RDONLY) = 33
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---
+++ killed by SIGSEGV +++

Yes?

Edit: Yes! That was it! After re-enabling IPv6 the application no longer segfaults where it used to. Thank you!

Edit2: Perhaps it's wrong to point my finger at libdnet here, but definetly something doesn't like IPv6 not being available. That "something" might well be further up the chain though. And yes, I know we all need to learn to memorize things like 2001:0000:130F:0000:0000:09C0:876A:130B instead of 192.168.1.2, because IoT, but I'm just too old for that. Hell, I'm too old to even remember configuring firewall rules for "that other thing" - which is why I tend to turn it off when it's not needed.

[clickworkorange]

Closing, with thanks to @ofalk for reminding me that actually looking at what's happening on your own system is sometimes often better than Googling.

[ofalk]

Ohh well. IPv6, my good ol' friend. Great you've been able to figure it out with my little hint with strace. Great my good old sysadmin skills sometimes still help :-)