FS#79655 - networkmanager 1.44.0-1 + ppp 2.5.0-1 don't play nicely with renamed nm connections
Attached to Project:
Arch Linux
Opened by Bill Sideris (bill88t) - Monday, 11 September 2023, 15:08 GMT
Last edited by Toolybird (Toolybird) - Tuesday, 12 September 2023, 20:46 GMT
Opened by Bill Sideris (bill88t) - Monday, 11 September 2023, 15:08 GMT
Last edited by Toolybird (Toolybird) - Tuesday, 12 September 2023, 20:46 GMT
|
Details
Description:
First things first. Thinkpad T480 and a 2-month-ish setup w/ KDE. Nothing special (like manual configs) done with either of those packages. I have configured a "Hotspot" connection via KDE, that I use frequently. And it has worked flawlessly up till those upgrades. I installed the updates like regular and restarted my system. All fine and dandy till I decided to enable the AP like regular. It started up and worked till the first device connected. Then.. "wait, where my nm applet go?" nm had segfaulted, and even left the dnsmasq process behind. After killing dnsmasq to free the ip range and restarting nm, I tried again only for the same thing to happen. I then downgraded nm instinctively to 1.42.6-1 and life is good. I came here then, to see and potentially report it (it's my first bug report in here), but I found Weirdly enough, if I upgrade nm back to 1.44 and downgrade ppp to 2.4.9-3, the issue doesn't happen. It only happens when both nm and ppp are on latest. Additional info: * networkmanager 1.44.0-1 / 1.42.6-1 * ppp 2.5.0-1 / 2.4.9-3 Steps to reproduce: It's probably related to kde and nm renamed connections. So: - Have an arch + kde setup with everything on the latest version. - Make a custom networkmanager connection. - Rename that connection. - Have something connect to that connection? - Segfault! Do keep in mind, that after an nm crash on a AP connection, dnsmasq is effective a zombie process, blocking the connection from restarting by keeping the ip range to itself. You have to kill it to retry. |
This task depends upon
Closed by Toolybird (Toolybird)
Tuesday, 12 September 2023, 20:46 GMT
Reason for closing: Duplicate
Additional comments about closing: FS#79658
Tuesday, 12 September 2023, 20:46 GMT
Reason for closing: Duplicate
Additional comments about closing:
Note also
FS#79658(maybe related, maybe not). Anyway, can you please post a backtrace containing debug symbols [1]? It's often as simple as this (with gdb installed):$ coredumpctl gdb (then answer y when it asks "Enable debuginfod for this session?")
(gdb) set logging enabled
(gdb) bt (or bt full)
Then post gdb.txt
But the chances are this is all ppp related i.e.
FS#79639FS#79642[1] https://wiki.archlinux.org/title/Debugging/Getting_traces
I tried also downloading the debug symbols for glibc, but those weren't used it so seems. I don't know how to force it to use them and populate the whole thing.
Note: I haven't used the systemd coredump stuff before.
I hope this helps.
FS#79658from the backtrace. Can you reproduce with glib2 2.78.0-2?https://bbs.archlinux.org/viewtopic.php?pid=2120223
So it was just glib2 at fault I guess.