FS#64771 - [xss-lock] crash after closing X

Attached to Project: Community Packages
Opened by singe infini (singeinfini) - Sunday, 08 December 2019, 11:46 GMT
Last edited by freswa (frederik) - Sunday, 13 September 2020, 10:08 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Giancarlo Razzolini (grazzolini)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
xss-lock generates a coredump after closing X session, maybe due to misuse of glib2 (view attached file)
--
Coredump info:
PID: 2290 (xss-lock)
UID: 1000 (singe)
GID: 985 (users)
Signal: 5 (TRAP)
Timestamp: Sun 2019-12-08 12:19:17 CET (11min ago)
Command Line: xss-lock --transfer-sleep-lock -- i3lock --nofork
Executable: /usr/bin/xss-lock
Control Group: /user.slice/user-1000.slice/session-6.scope
Unit: session-6.scope
Slice: user-1000.slice
Session: 6
Owner UID: 1000 (singe)
Boot ID: 02086c04b25d4ef9bb4a38bb1edf0fca
Machine ID: 1e1acb9171974ee7aca2d78c5164fbdf
Hostname: hostname
Storage: /var/lib/systemd/coredump/core.xss-lock.1000.02086c04b25d4ef9bb4a38bb1edf0fca.2290.1575803957000000000000.lz4
Message: Process 2290 (xss-lock) of user 1000 dumped core.

Stack trace of thread 2290:
#0 0x00007fc2d4825166 n/a (libglib-2.0.so.0 + 0x64166)
#1 0x00007fc2d48253b8 g_logv (libglib-2.0.so.0 + 0x643b8)
#2 0x00007fc2d48255a0 g_log (libglib-2.0.so.0 + 0x645a0)
#3 0x0000564904a8541e n/a (xss-lock + 0x341e)
#4 0x0000564904a8559f n/a (xss-lock + 0x359f)
#5 0x00007fc2d482b26f g_main_context_dispatch (libglib-2.0.so.0 + 0x6a26f)
#6 0x00007fc2d482d1b1 n/a (libglib-2.0.so.0 + 0x6c1b1)
#7 0x00007fc2d482e0c3 g_main_loop_run (libglib-2.0.so.0 + 0x6d0c3)
#8 0x0000564904a8461a main (xss-lock + 0x261a)
#9 0x00007fc2d43ea153 __libc_start_main (libc.so.6 + 0x27153)
#10 0x0000564904a8478a _start (xss-lock + 0x278a)

Stack trace of thread 2293:
#0 0x00007fc2d44b79ef __poll (libc.so.6 + 0xf49ef)
#1 0x00007fc2d482d120 n/a (libglib-2.0.so.0 + 0x6c120)
#2 0x00007fc2d482d1f1 g_main_context_iteration (libglib-2.0.so.0 + 0x6c1f1)
#3 0x00007fc2d482d242 n/a (libglib-2.0.so.0 + 0x6c242)
#4 0x00007fc2d4809bb1 n/a (libglib-2.0.so.0 + 0x48bb1)
#5 0x00007fc2d43124cf start_thread (libpthread.so.0 + 0x94cf)
#6 0x00007fc2d44c22d3 __clone (libc.so.6 + 0xff2d3)

Stack trace of thread 2294:
#0 0x00007fc2d44bce9d syscall (libc.so.6 + 0xf9e9d)
#1 0x00007fc2d47de11b g_cond_wait_until (libglib-2.0.so.0 + 0x1d11b)
#2 0x00007fc2d485bef3 n/a (libglib-2.0.so.0 + 0x9aef3)
#3 0x00007fc2d485c0e4 g_async_queue_timeout_pop (libglib-2.0.so.0 + 0x9b0e4)
#4 0x00007fc2d480302a n/a (libglib-2.0.so.0 + 0x4202a)
#5 0x00007fc2d4809bb1 n/a (libglib-2.0.so.0 + 0x48bb1)
#6 0x00007fc2d43124cf start_thread (libpthread.so.0 + 0x94cf)
#7 0x00007fc2d44c22d3 __clone (libc.so.6 + 0xff2d3)

Stack trace of thread 2295:
#0 0x00007fc2d44b79ef __poll (libc.so.6 + 0xf49ef)
#1 0x00007fc2d482d120 n/a (libglib-2.0.so.0 + 0x6c120)
#2 0x00007fc2d482e0c3 g_main_loop_run (libglib-2.0.so.0 + 0x6d0c3)
#3 0x00007fc2d499bbc8 n/a (libgio-2.0.so.0 + 0x59bc8)
#4 0x00007fc2d4809bb1 n/a (libglib-2.0.so.0 + 0x48bb1)
#5 0x00007fc2d43124cf start_thread (libpthread.so.0 + 0x94cf)
#6 0x00007fc2d44c22d3 __clone (libc.so.6 + 0xff2d3)
--

Additional info:
* xss-lock 0.3.0.g1e158fb20108-2,
* glib2 2.62.3-1

Steps to reproduce:
- With i3wm/i3lock default config ensure the following line is uncommented:
exec --no-startup-id xss-lock -v --transfer-sleep-lock -- i3lock --nofork

- launch i3 then exit with $mod+Shift+e
This task depends upon

Closed by  freswa (frederik)
Sunday, 13 September 2020, 10:08 GMT
Reason for closing:  Fixed
Additional comments about closing:  0.3.0.g1e158fb20108-4
Comment by Giancarlo Razzolini (grazzolini) - Friday, 17 January 2020, 14:43 GMT
I have tried to reproduce it here and I was not able to do so. Can you rebuild xss-lock and glib2 with debugging symbols? Also, does this issue only happen on closing a X session, or it also happens when suspending?
Comment by singe infini (singeinfini) - Tuesday, 21 January 2020, 20:36 GMT
It only happens on closing X. According to https://bitbucket.org/raymonad/xss-lock/issues/19/xss-lock-shouldnt-exit-with-sigabrt-on-x the behavior is related to an improper call to g_critical.
As a temporary workaround the following key binding can be used:
bindsym $mod+Shift+e exec "i3-nagbar -t warning -m 'You pressed the exit shortcut. Do you really want to exit i3? This will end your X session.' -B 'Yes, exit i3' 'killall xss-lock && i3-msg exit'"
Comment by Giancarlo Razzolini (grazzolini) - Friday, 24 January 2020, 19:34 GMT
I can confirm this bug. I'm not sure what's the best approach to fix it, and it seems the project is dead (again). I almost never close X like that, I usually suspend or power down directly, so I didn't notice this bug before.
Comment by Angelo Geulin (arvl) - Sunday, 28 June 2020, 04:16 GMT
For anyone else hitting this bug, this patch from Debian fixes the issue for me. There is also a 'tentative patch' in the linked issue that should fix it, but I haven't tried that.

Loading...