i3lock raise_loop process does not exit about i3lock HOT 12 CLOSED

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?

from i3lock.

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.

from i3lock.

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.

from i3lock.

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.

from i3lock.

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.

from i3lock.

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.

from i3lock.

@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?

from i3lock.

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

from i3lock.

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

from i3lock.

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.

from i3lock.

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.

from i3lock.

This fixes it:

commit 1158c89fa24d799463253d7676c67dc095cf88f1
Author: Martin T. H. Sandsmark <[email protected]>
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;
 }

from i3lock.