! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
xfce4-power-manager segfaults upon shutdown causing very slow shutdowns with ...
Status:
RESOLVED: FIXED
Product:
Xfce4-power-manager
Component:
General

Comments

Description Jaroslav Škarvada 2016-02-23 11:40:30 CET
Created attachment 6619 
Naive fix for the problem

The issue is currently reported in Fedora downstream bugzilla against xfce4-power-manager and against systemd as:
https://bugzilla.redhat.com/show_bug.cgi?id=1310871
https://bugzilla.redhat.com/show_bug.cgi?id=1310608

The problem is that xfce4-power-manager segfaults during machine shutdown (with more than 60% probability on my machine) which caused systemd to spawn systemd-coredump process dumping and compressing the core, which takes a long time (usually more than systemd preset 90 seconds timeout) and the systemd-coredump process is killed after this timeout and nothing is logged/dumped. As a result it is very confusing and causes useless 90 seconds timeouts during machine shutdown. According to the systemd upstream tracker, it seems there are more users expecting this problem.

The underlying problem for this is probably the xfce4-power-manager segfault with the following backtrace:

#0  0x00007f8890ff3b3a in strlen () at /lib64/libc.so.6
#1  0x000055b775fab868 in get_device_description (upower=0x7f8874009270, device=device@entry=0x7f88740394e0)
    at xfpm-power-common.c:267
#2  0x000055b775fa7526 in power_manager_button_update_device_icon_and_details (button=0x55b777b04230, device=0x7f88740394e0)
    at ../panel-plugins/power-manager-plugin/power-manager-button.c:454
#3  0x00007f88922ee7a5 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#4  0x00007f8892300851 in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#5  0x00007f8892309530 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#6  0x00007f88923098ff in g_signal_emit () at /lib64/libgobject-2.0.so.0
#7  0x00007f88922f2cd4 in g_object_dispatch_properties_changed () at /lib64/libgobject-2.0.so.0
#8  0x00007f88922f51c1 in g_object_notify () at /lib64/libgobject-2.0.so.0
#9  0x00007f88922ee7a5 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#10 0x00007f8892300851 in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#11 0x00007f8892309530 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#12 0x00007f88923098ff in g_signal_emit () at /lib64/libgobject-2.0.so.0
#13 0x00007f88922f2cd4 in g_object_dispatch_properties_changed () at /lib64/libgobject-2.0.so.0
#14 0x00007f88922f51c1 in g_object_notify () at /lib64/libgobject-2.0.so.0
#15 0x00007f889254692f in up_device_glue_proxy_g_properties_changed () at /lib64/libupower-glib.so.3
#16 0x00007f888c3dad30 in ffi_call_unix64 () at /lib64/libffi.so.6
#17 0x00007f888c3da79b in ffi_call () at /lib64/libffi.so.6
#18 0x00007f88922eefc9 in g_cclosure_marshal_generic () at /lib64/libgobject-2.0.so.0
#19 0x00007f88922ee7a5 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#20 0x00007f8892300dfe in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#21 0x00007f8892309530 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#22 0x00007f88923098ff in g_signal_emit () at /lib64/libgobject-2.0.so.0
#23 0x00007f889283283d in on_name_owner_changed () at /lib64/libgio-2.0.so.0
#24 0x00007f8892822554 in emit_signal_instance_in_idle_cb () at /lib64/libgio-2.0.so.0
#25 0x00007f8891fefe3a in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#26 0x00007f8891ff01d0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#27 0x00007f8891ff04f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#28 0x00007f8894830255 in gtk_main () at /lib64/libgtk-3.so.0
#29 0x000055b775f934db in xfpm_start (bus=<optimized out>, client_id=0x0, dump=<optimized out>) at xfpm-main.c:240
#30 0x000055b775f93b4f in main (argc=1, argv=0x7ffe2e113e48) at xfpm-main.c:447

I think it segfaults because either 'vendor' or 'model' is NULL. I am not sure whether it is allowed, maybe there is also upower bug, but I think the client (xfce4-power-manager) should handle even such strange cases. The attached patch is my naive approach to fix the segfault. Maybe it's better to exit or do some different thing than just injecting empty string ("") instead of NULLs. I am now testing it whether it resolved the slow shutdown problem for me. Any comments are highly welcome.
Comment 1 Jaroslav Škarvada 2016-02-25 09:26:03 CET
It seems the patch resolved the problem for me - no more crash in last two days.
Comment 2 Eric Koegel editbugs 2016-02-25 17:47:15 CET
Thanks! Honestly we probably only need to handle the model being NULL, but seeing as we already got that wrong, it is better to be extra safe. 
Pushed your patch to master in:
commit 7b1e006c8eaebf16a449b890416f3fea927f6d48
Author: Eric Koegel <eric.koegel@gmail.com>
Date:   Thu Feb 25 19:40:49 2016 +0300

    Fix a crash on logout (Bug #12465)
    
    During session shutdown we were in a situation with a NULL model
    which was crashing a crash. Set these to an empty string so xfpm
    properly handles it.
    Reported and fixed by Jaroslav Škarvada.
    
    Signed-off-by: Eric Koegel <eric.koegel@gmail.com>
http://git.xfce.org/xfce/xfce4-power-manager/commit/?id=7b1e006c8eaebf16a449b890416f3fea927f6d48

Bug #12465

Reported by:
Jaroslav Škarvada
Reported on: 2016-02-23
Last modified on: 2016-02-25

People

Assignee:
Ali Abdallah
CC List:
4 users

Version

Attachments

Naive fix for the problem (564 bytes, text/plain)
2016-02-23 11:40 CET , Jaroslav Škarvada
no flags

Additional information