-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
segtault in systemd-networkd #16299
Comments
If you have the coredump, load it into gdb like What's shown above isn't really actionable in isolation. |
This was odd... I wasn't expecting .reg-xstate/707 or missing symbols... gdb /lib/systemd/systemd-networkd /root/core.systemd-network.114.eeaf36bce83842ebb0b8637976e623fa.707.1593289203000000000000 For help, type "help". warning: core file may not match specified executable file. warning: Unexpected size of section warning: Unexpected size of section `.reg-xstate/707' in core file. And decodecode gives very little.. Code: 83 fb 77 0f 87 a4 01 00 00 48 8b 5c 24 18 4c 01 e3 e9 53 ff ff ff 0f 1f 80 00 00 00 00 48 8b 85 08 02 00 00 41 bc 00 87 93 03 <8b> 58 08 2b 58 04 83 fb 77 0f 87 5c 01 00 00 48 8b 5c 24 18 4c 01
|
If you're able to easily reproduce this, rebuilding with debug symbols as this is gentoo, and getting another core dump && backtrace with the symbols would be helpful. I think you'd just re-emerge systemd w/nostrip. However, with what you already have, it'd be useful to know if %rax is non-NULL, so could you paste the output of |
(gdb) info registers |
the thing is, it should be built with debug already, split but still debug - will look in to it, =) |
As a sidenote, the /lib/ path is what breaks the split debug - have a newly built version, and I'll see when it happens, don't really want to force it atm |
So %rax is NULL, it segfaulted on a NULL pointer dereference. That's far more tractable than some random memory address. I don't have time to try figure out where exactly that code is, but if you get debugging symbols I imagine this shouldn't be too bad to figure out. At a glance, those cmps against 0x77 are suggestive of SD_DHCP_OPTION_DOMAIN_SEARCH_LIST that is 119. |
Please provide a backtrace with debug symbols, otherwise this simply isn't actionable for us. If you distro doesn't provide debug symbols then this isn't debuggable to us and there's nothing we can do. |
Please also provide your configs (.network and .netdev files) and debugging logs. |
Something similar just happened... Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/lib/systemd/systemd-networkd'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Unexpected size of section `.reg-xstate/831639' in core file.
#0 0x0000562e7a9b7b5d in client_timeout_resend (s=<optimized out>, usec=<optimized out>, userdata=0x562e7ab14e60) at ../systemd-stable-245.5/src/libsystemd-network/sd-dhcp-client.c:1074
1074 ../systemd-stable-245.5/src/libsystemd-network/sd-dhcp-client.c: No such file or directory.
(gdb) bt full
#0 0x0000562e7a9b7b5d in client_timeout_resend (s=<optimized out>, usec=<optimized out>, userdata=0x562e7ab14e60) at ../systemd-stable-245.5/src/libsystemd-network/sd-dhcp-client.c:1074
client = 0x562e7ab14e60
_dont_destroy_client = 0x562e7ab14e60
next_timeout = 0
time_now = 619511910366
time_left = <optimized out>
r = 0
__PRETTY_FUNCTION__ = "client_timeout_resend"
__func__ = "client_timeout_resend"
#1 0x00007f7753800e96 in source_dispatch (s=s@entry=0x562e7ab0c230) at ../systemd-stable-245.5/src/libsystemd/sd-event/sd-event.c:3201
saved_type = SOURCE_TIME_BOOTTIME
r = <optimized out>
__PRETTY_FUNCTION__ = "source_dispatch"
__func__ = "source_dispatch"
#2 0x00007f7753803580 in sd_event_dispatch (e=e@entry=0x562e7aac2f20) at ../systemd-stable-245.5/src/libsystemd/sd-event/sd-event.c:3634
ref = <optimized out>
p = <optimized out>
r = <optimized out>
__PRETTY_FUNCTION__ = "sd_event_dispatch"
#3 0x00007f7753803748 in sd_event_run (e=e@entry=0x562e7aac2f20, timeout=timeout@entry=18446744073709551615) at ../systemd-stable-245.5/src/libsystemd/sd-event/sd-event.c:3692
r = 1
__PRETTY_FUNCTION__ = "sd_event_run"
#4 0x00007f7753803967 in sd_event_loop (e=0x562e7aac2f20) at ../systemd-stable-245.5/src/libsystemd/sd-event/sd-event.c:3714
ref = 0x562e7aac2f20
r = <optimized out>
__PRETTY_FUNCTION__ = "sd_event_loop"
#5 0x0000562e7a94d111 in run (argv=<optimized out>, argc=1) at ../systemd-stable-245.5/src/network/networkd.c:123
notify_message = 0x562e7a9d2000 "STOPPING=1\nSTATUS=Shutting down..."
m = 0x562e7aac2d40
r = 0
notify_message = <optimized out>
m = <optimized out>
r = <optimized out>
__func__ = "run"
__PRETTY_FUNCTION__ = "run"
_level = <optimized out>
_e = <optimized out> |
Please provide journal logs and configs. |
(gdb) p client So that explains it... |
journal:
|
Sorry, it seems like there was a new segfault during the night... And this is with the patches applied warning: Unexpected size of section `.reg-xstate/694' in core file. |
Follow-up for ceaec54. Hopefully fixes systemd#16299.
Hmm, could you test PR #16470? Thank you for the report and your cooperation. |
Built and running now... Btw, does systemd-networkd's dhcp act correctly? I get a new ip for each lease which seems odd to me, esp when I should have time left on the last lease... |
If you experienced a strange behavior in networkd, then please enable to generate debugging logs by creating /etc/systemd/system/systemd-networkd.service.d/override.conf as
, and then please provide the logs. |
That's probably because systemd-networkd is sending a DHCP RELEASE when it stops, causing the server to terminate the lease. Try putting "SendRelease=no" in the "[DHCPv4]" section. That should help. |
systemd version the issue has been seen with
Used distribution
Expected behaviour you didn't see
Unexpected behaviour you saw
Steps to reproduce the problem
Unknown, happens all the time, filing this bugreport so that you can get more information.
journactl:
jun 27 22:20:03 byte systemd-networkd[707]: vnet7: Link UP
jun 27 22:20:03 byte systemd-networkd[707]: vnet7: Gained carrier
jun 27 22:20:04 byte systemd[1]: systemd-networkd.service: Main process exited, code=dumped, status=11/SEGV
jun 27 22:20:04 byte systemd[1]: systemd-networkd.service: Failed with result 'core-dump'.
jun 27 22:20:04 byte systemd[1]: systemd-networkd.service: Scheduled restart job, restart counter is at 1.
jun 27 22:20:04 byte systemd[1]: Stopped Network Service.
jun 27 22:20:04 byte systemd[1]: Starting Network Service...
dmesg:
[ 11.926344] systemd-network[707]: segfault at 8 ip 000055a60fc4d2dd sp 00007fff929ffcd0 error 4 in systemd-networkd[55a60fbe1000+87000]
[ 11.926354] Code: 83 fb 77 0f 87 a4 01 00 00 48 8b 5c 24 18 4c 01 e3 e9 53 ff ff ff 0f 1f 80 00 00 00 00 48 8b 85 08 02 00 00 41 bc 00 87 93 03 <8b> 58 08 2b 58 04 83 fb 77 0f 87 5c 01 00 00 48 8b 5c 24 18 4c 01
I also have the coredump if it would be useful
The text was updated successfully, but these errors were encountered: