compton stopped by i3lock

Ramb0 · 2019-06-20 10:44:53

Dear community,
I'm running i3-gaps with compton on Arch Linux. I lock my screen with i3lock.
Everytime I unlock my screen using i3lock then compton is stopped.
The logs don't show anything interesting.
When using strace to monitor compton's behaviour regarding system calls I notice that it seems to die when unlocking. I suspect that compton is not handling SIGCONT properly. Is this problem familiar?

Here is the strace listening to compton:

getpid()                                = 1051
getpid()                                = 1051
write(2, "XIO:  fatal IO error 11 (Resourc"..., 77) = 77
write(2, "      after 13366 requests (1336"..., 77) = 77
futex(0x5609b683c438, FUTEX_WAKE_PRIVATE, 2147483647) = 1
futex(0x5609b683c3e8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f40f60879d0, FUTEX_WAIT, 1079, NULL) = -1 EAGAIN (Resource temporarily unavailable)
getpid()                                = 1051
munmap(0x7f40f5867000, 131072)          = 0
munmap(0x7f40f79b5000, 131072)          = 0
exit_group(1)                           = ?
+++ exited with 1 +++

Many thank yous

Last edited by Ramb0 (2019-06-20 22:00:28)

seth · 2019-06-20 11:57:57

kill -SIGSTOP `pidof compton`; sleep 5; kill -SIGCONT `pidof compton`

works as one would expect here.
Also running cmopton and briefly i3lock'ing has no further impact here.

The strace tail doesn't suggest a SIGSTOP/CONT at all but compton has trouble talking to X11 and after a lot of failed requests aborts.

a) does the lock duration matter?
b) do you have more strace?

Edit: if you've "more strace™" please either use a pastebin service or code tags to post it, thanks.

Last edited by seth (2019-06-20 11:58:34)

Ramb0 · 2019-06-21 01:27:12

Thanks for your reply @seth
I tried sending signals as you suggested and that works fine. So I was wrong, it is not the signals.

I launched strace with more options to get the timestamps. Here are the last 1000 lines of the strace log. Only the very end is interesting. I locked the screen at 08:14:00 and unlocked it at 08:14:10. As you can see compton actually stops when I lock the screen.

https://slexy.org/raw/s2Rtxnx84z?token= … 1561079083

seth · 2019-06-21 07:09:43

It doesn't stop but aborts (or exits w/ code "1" for any other reason)

I find the getpid spam suspicious, rather try to run compton in gdb to figure what actually calls getpid and whether and maybe why comptom aborts
(since it's the compositor, attaching/controlling gdb from ssh should be more comfortable - run "echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope" to be able to attach to running processes)

I guess it doesn't like something that happens to some other window - do you just run i3lock or more stuff (eg. a script that stops certain clients)?
Your i3lock config?

Ramb0 · 2019-06-22 02:54:05

I tried running compton from gdb as trying to attach to the compton already running process freezes i3 (but not the mouse). Maybe that's also a clue...?

I run

i3lock --show-failed-attempts --color=000000

which seems quite vanilla.

That's the only thing I got:

$ gdb `which compton`
GNU gdb (GDB) 8.3
...
Reading symbols from /usr/bin/compton...
(No debugging symbols found in /usr/bin/compton)
(gdb) r
Starting program: /usr/bin/compton 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff4ce5700 (LWP 7875)]
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
      after 3098 requests (3080 known processed) with 0 events remaining.
[Thread 0x7ffff4ce5700 (LWP 7875) exited]
[Inferior 1 (process 7871) exited with code 01]
(gdb) backtrace
No stack.

Should I try to run gdb from the compton source code with symbols or is it an overkill?

Last edited by Ramb0 (2019-06-22 02:55:52)

seth · 2019-06-22 07:17:00

Why has it left the stack?
The halting compton likely would have frozen the screen (like attaching it, "continue" is the word ;-) - did you maybe kill it because of that?

Ramb0 · 2019-06-22 08:46:44

Sorry I got confused and I must edit this reply entirely.

In my previous post there is no stack because it was an example of compton stopping after I locked the screen.

When I attached gdb to compton with

 gdb `which compton` `pidof compton`

it works and when placing a breakpoint on getpid here is the stack I get:

(gdb) backtrace
#0  0x00007ffff7e92670 in getpid () from /usr/lib/libc.so.6
#1  0x00007ffff6e2a68a in ?? () from /usr/lib/libGLX.so.0
#2  0x00007ffff6e2cc19 in ?? () from /usr/lib/libGLX.so.0
#3  0x00007ffff6e2fc91 in ?? () from /usr/lib/libGLX.so.0
#4  0x00007ffff6e29341 in glXQueryExtensionsString () from /usr/lib/libGLX.so.0
#5  0x0000555555564fc7 in ?? ()
#6  0x000055555556ce22 in ?? ()
#7  0x000055555557e378 in ?? ()
#8  0x000055555555d31f in ?? ()
#9  0x00007ffff7dedce3 in __libc_start_main () from /usr/lib/libc.so.6
#10 0x000055555555dd0e in ?? ()

Last edited by Ramb0 (2019-06-22 09:04:05)

seth · 2019-06-22 11:56:33

Seems comptons asks for the GL extensions a bit often then ;-)

Rather put a breakpoint on exit_group so we can see where the process exit is coming from.

Ramb0 · 2019-06-23 00:02:05

Putting a breakpoint on exit_group did not work. For some reason the program stops and skips it.

So I decided to run gdb with the symbols instead. I built compton from source code on git.

I tried https://github.com/chjj/compton which works 100% fine with locking/unlocking the screen. Unfortunately this is not the code used by the compton that was originally installed on my machine (the one given by pacman)

This is the one given by pacman: https://github.com/yshui/compton

When I run this one (yshui) it also stops when I lock the screen and outputs:

x_new_id FATAL ERROR ] We seems to have run of XIDs. This is either a bug in the X server, or a resource leakage in compton. Please open an issue about this problem. compton will die.
[1]    615 abort (core dumped)  ./compton

Here is the coredump:

Program terminated with signal SIGABRT, Aborted.
#0  0x00007f61c167982f in raise () from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x7f61c0ebf940 (LWP 615))]
(gdb) backtrace
#0  0x00007f61c167982f in raise () from /usr/lib/libc.so.6
#1  0x00007f61c1664672 in abort () from /usr/lib/libc.so.6
#2  0x000056048cce2a8d in x_new_id.part.7.cold ()
#3  0x000056048ccfe6c8 in paint_one ()
#4  0x000056048ccfeb8e in paint_all ()
#5  0x000056048cce7385 in _draw_callback.isra.19 ()
#6  0x000056048cce7640 in draw_callback ()
#7  0x00007f61c23e3993 in ev_invoke_pending () from /usr/lib/libev.so.4
#8  0x00007f61c23e72dd in ev_run () from /usr/lib/libev.so.4
#9  0x000056048cce4025 in main ()

So it seems it can't get a new X_id. I don t have much knowledge about X server.
Does it make sense for me to raise the problem in the corresponding git issues reporting?

seth · 2019-06-23 05:17:08

Yes (you're explicity asked so ;-)
You can already try this patch to see whether compton leaks IDs in this function (but more likely the problem will just popup somewhere else)

Did you invoke i3lock directly from an interactive shell or shortcut (in contrast to some xautolock)? Does it matter?

--- render.c	2019-06-23 07:12:09.036232771 +0200
+++ render.c	2019-06-23 07:08:37.988944449 +0200
@@ -249,7 +249,7 @@ static inline bool paint_isvalid(session
 void paint_one(session_t *ps, struct managed_win *w, const region_t *reg_paint) {
 	// Fetch Pixmap
 	if (!w->paint.pixmap) {
-		w->paint.pixmap = x_new_id(ps->c);
+		w->paint.pixmap = -1; //x_new_id(ps->c);
 		set_ignore_cookie(ps, xcb_composite_name_window_pixmap(ps->c, w->base.id,
 		                                                       w->paint.pixmap));
 	}

Ramb0 · 2019-06-23 11:01:35

I just realised the problem only happens only when I use my laptop connected to a larger screen (multiscreen setup)!! In retrospect I should have tried earlier, apologies.

I tried the pixmap=-1 suggestion from your reply but pixmap is an unsigned int. So I tried with 0 and max_unsigned_int but both produce errors at execution and compton does not work at all.

Ramb0 · 2019-06-23 11:28:46

I posted the problem on github:
https://github.com/yshui/compton/issues/196

It looks like somebody else had a similar but different problem a few days ago:
https://github.com/yshui/compton/issues/190

Arch Linux

#1 2019-06-20 10:44:53

compton stopped by i3lock

#2 2019-06-20 11:57:57

Re: compton stopped by i3lock

#3 2019-06-21 01:27:12

Re: compton stopped by i3lock

#4 2019-06-21 07:09:43

Re: compton stopped by i3lock

#5 2019-06-22 02:54:05

Re: compton stopped by i3lock

#6 2019-06-22 07:17:00

Re: compton stopped by i3lock

#7 2019-06-22 08:46:44

Re: compton stopped by i3lock

#8 2019-06-22 11:56:33

Re: compton stopped by i3lock

#9 2019-06-23 00:02:05

Re: compton stopped by i3lock

#10 2019-06-23 05:17:08

Re: compton stopped by i3lock

#11 2019-06-23 11:01:35

Re: compton stopped by i3lock

#12 2019-06-23 11:28:46

Re: compton stopped by i3lock

Board footer