i3lock raise_loop process does not exit

[tcatm]

In raise_loop i3lock is waiting for events on its window. On a few occasions this has caused i3lock to not exit on my system after unlocking. At best, this causes stray processes and at worst it prevents locking the screen when external scripts check whether the previous i3lock run terminated.

By analysing the running i3lock process using gdb I have found the window it is waiting for doesn't exist anymore (Obvisouly, this is expected as my session is unlocked). I'm going to run i3lock with --debug from now on so I get a better idea of what's going on.

I can't reproduce this yet.

[stapelberg]

I’ve renamed this to a more accurate description. The forked process which raises the window should exit when the main process exits.

Steps to reproduce would be appreciated.

[tcatm]

I've encountered the problem again. According to the debug log i3lock is watching window 0x04800003 and it is also receiving an UnmapNotify for 0x04800003. Yet, when I attach gdb to the process the variable window in raise_loop is set to 0x04800006.

[stapelberg]

That’s really peculiar. raise_loop never writes to window, so the fact that it changed might mean that there is memory corruption somewhere in i3lock. Could you run i3lock under valgrind please?

On my machine, DISPLAY=:0 valgrind --log-file=/tmp/valgrind.log --leak-check=full --track-origins=yes --num-callers=20 --tool=memcheck -v -- ./i3lock -n does not find any errors in /tmp/valgrind.log, but possibly this problem only shows on certain configurations.

[Airblader]

I have encountered this problem last night as well. My screen was unlocked, but there was still a running i3lock process that I had to kill. It definitely doesn't happen very often, in fact, it's the first time it happened for me. My i3lock call is

i3lock -n -u -t -i /path/to/some/image.png

Running this call under the above valgrind doesn't really show anything, just a few minor things in cairo.

[bblough]

I'm seeing this on multiple systems. Unfortunately, I don't have steps to reproduce, but I have some additional info that may (or may not) be helpful.

On one system, I see an extra process or two every couple of days. On the other system, I get several extra processes per day, even if I haven't unlocked the system.

For example, I last unlocked/relocked that system yesterday. At that time, I killed all i3lock processes. I haven't unlocked that system since, but running ps via ssh I can see that there are 7 i3lock processes now running. From the times in ps -ef, the largest interval between processes is several hours, the shortest is 30 minutes.

If I let that system go for a couple of weeks without killing those stray processes, I'll eventually not be able to open any more X programs ("maximum number of clients reached"), which is what originally tipped me off to this problem.

[stapelberg]

@bblough Could you run i3lock under xtrace (see https://xtrace.alioth.debian.org/) and provide the xtrace logfile of a run where the problem occurs?

[bblough]

Interestingly, I haven't been able to reproduce the problem under xtrace. I'll have to experiment some more.

[lemuelroberto]

Same thing happened here. Unfortunately I can't help with more details on how to reproduce the bug. My i3lock call is

i3lock -i /path/to/img/001.png

I'm using Ubuntu 14.04.4, i3 version 4.12 and i3lock: version 2.7

[sandsmark]

tcatm, did you verify that it was the same thread/pid?

I also experience this from time to time, but I haven't found any way to consistently reproduce it, which is to be expected if it is memory clobbering I guess. I think I'll try to reduce this to a smaller test case that can be run quickly in a loop.

[sandsmark]

It seems like «[i3lock-debug] X11 Error received! sequence 0x1, error_code = 3» is printed (only) when this bug is triggered. I can also trigger it pretty consistently while running under valgrind.

[sandsmark]

Error 3 is BadWindow, and since it happens more often when running under valgrind slowing everything down, I suspect xcb_change_window_attributes is called before the window is ready, somehow?

[sandsmark]

This fixes it:

commit 1158c89fa24d799463253d7676c67dc095cf88f1
Author: Martin T. H. Sandsmark <martin.sandsmark@kde.org>
Date:   Sun May 15 14:40:07 2016 +0200

    Flush xcb connection after opening fullscreen window

    We need to ensure that the window handle is usable before returning so
    it can be used immediately.

    Fixes #46

diff --git a/xcb.c b/xcb.c
index f1a9a76..f8ac1b3 100644
--- a/xcb.c
+++ b/xcb.c
@@ -150,6 +150,9 @@ xcb_window_t open_fullscreen_window(xcb_connection_t *conn, xcb_screen_t *scr, c
     values[0] = XCB_STACK_MODE_ABOVE;
     xcb_configure_window(conn, win, XCB_CONFIG_WINDOW_STACK_MODE, values);

+    /* Ensure that the window is created and set up before returning */
+    xcb_flush(conn);
+
     return win;
 }