Created attachment 136061 [details] gdb backtrace of the crash I got a random crash in upower 0.99.6-1 running on Debian buster. If the below gdb backtrace and the attached full gdb backtrace isn't useful, please close this bug. The core file will be automatically deleted in one week. Core was generated by `/usr/lib/upower/upowerd'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000563bf5623740 in up_backend_inhibitor_lock_take (backend=0x563bf61934a0) at up-backend.c:501 501 up-backend.c: No such file or directory. [Current thread is 1 (Thread 0x7fd118c38ec0 (LWP 22780))] #0 0x0000563bf5623740 in up_backend_inhibitor_lock_take (backend=0x563bf61934a0 [UpBackend]) at up-backend.c:501 #1 0x00007fd117e60745 in g_type_create_instance (type=<optimized out>) at ../../../../gobject/gtype.c:1866 #2 0x00007fd117e415e8 in g_object_new_internal (class=class@entry=0x563bf61a2e70, params=params@entry=0x0, n_params=n_params@entry=0) at ../../../../gobject/gobject.c:1797 #3 0x00007fd117e42d85 in g_object_new_with_properties (object_type=94815531969952, n_properties=0, names=names@entry=0x0, values=values@entry=0x0) at ../../../../gobject/gobject.c:1965 #4 0x00007fd117e43801 in g_object_new (object_type=<optimized out>, first_property_name=first_property_name@entry=0x0) at ../../../../gobject/gobject.c:1637 #5 0x0000563bf5624769 in up_backend_new () at up-backend.c:699 #6 0x0000563bf5610782 in up_daemon_init (daemon=0x563bf61a9150 [UpDaemon]) at up-daemon.c:1087 #7 0x00007fd117e60745 in g_type_create_instance (type=<optimized out>) at ../../../../gobject/gtype.c:1866 #8 0x00007fd117e415e8 in g_object_new_internal (class=class@entry=0x563bf61a82a0, params=params@entry=0x0, n_params=n_params@entry=0) at ../../../../gobject/gobject.c:1797 #9 0x00007fd117e42d85 in g_object_new_with_properties (object_type=94815531989392, n_properties=0, names=names@entry=0x0, values=values@entry=0x0) at ../../../../gobject/gobject.c:1965 #10 0x00007fd117e43801 in g_object_new (object_type=<optimized out>, first_property_name=first_property_name@entry=0x0) at ../../../../gobject/gobject.c:1637 #11 0x0000563bf5611efa in up_daemon_new () at up-daemon.c:1169 #12 0x0000563bf560fc14 in up_state_new () at up-main.c:72 #13 0x0000563bf560fc14 in main (argc=<optimized out>, argv=<optimized out>) at up-main.c:238
This is the line that crashes: https://cgit.freedesktop.org/upower/tree/src/linux/up-backend.c?h=UPOWER_0_99_6&id=98d98fcbd039e66eb161d1d1e44d079a15ae2ef4#n501 This means that g_dbus_proxy_call_with_unix_fd_list_sync() returns NULL without setting an error, which means some of the parameters must be invalid. Can you please check in the journalctl output around that time to see if there was a warning associated with this crash? Adding gicmo to the CC: list, as he wrote that code.
Unfortunately it looks like my journal messages from that period in time have expired. I'll try to look at my backups and get back to you.
Created attachment 137405 [details] edited version of systemd journal around the time of the crash Attached the normal journalctl output. If you need any of the fields of specific messages, let me know. Looking at the output, this was around the time of an apt upgrade, just afterwards when the needrestart hook was automatically restarting services that had library upgrades.
I fixed the crash. I don't know why it happens. Christian, can you please check this code again? commit c68daf665f2a5f09179cdf19fa9bcc0bf935b8ec Author: Bastien Nocera <hadess@hadess.net> Date: Thu Apr 12 22:32:13 2018 +0200 linux: Fix crash if logind doesn't return an error For example, when using an incomplete mock logind.
(In reply to Paul Wise from comment #3) > Looking at the output, this was around the time of an apt upgrade, just > afterwards when the needrestart hook was automatically restarting services > that had library upgrades. Christian pointed me to this section of the comment which I missed. This is exactly the sort of reason why we don't support doing live updates. The crash is fixed anyway.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.