xrandr error when switching displays - black rectangle

[pdijksta]

Output of i3 --moreversion 2>&- || i3 --version:

Binary i3 version: 4.12 (2016-03-06, branch "4.12") © 2009 Michael Stapelberg and contributors
Running i3 version: 4.12 (2016-03-06, branch "4.12") (pid 787)
Loaded i3 config: /home/philipp/.i3/config (Last modified: 2016-10-05T20:03:33 CEST, 2254952 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3

URL to a logfile as per http://i3wm.org/docs/debugging.html:

http://logs.i3wm.org/logs/5761253830033408.bz2

Description of the problem:

The full information can be found here: https://bbs.archlinux.org/viewtopic.php?id=217891

Sometimes upon calling xrandr to switch to an external display, me and at least 2 other i3 users experience a "weird rectangle" and we are unable to use that x session any more. While it is still possible to switch to another TTY, the x session becomes completely unresponsive, while the i3bar is still being updated. The cursor is caught in the rectangle.

It is possible to break out of that situation without having to kill i3 by mashing some keys. I have not been able to reproduce it. Probably, it is an interaction with the dmenu window.

Unfortunately we cannot give instructions on how to reproduce this bug, it seems to come at random. A lower resolution of the external display may be required as the OP of the forum thread suggested.

I can post the xorg log if needed.

Best regards,
Philipp

[Airblader]

That window you're seeing is the i3 crash dialog, it just isn't being rendered correctly (we have an open issue for that). You don't need to mash random keys, using "r" for reload or "f" for forgetting the layout is what restores the session because it restarts i3.

Could you please switch to another TTY when the crash occurs and pull a backtrace using gdb? That'll tell us right away where the crash occurs.

[pdijksta]

I have not used gdb before and since it will be inconvenient to search the web the next time it happens I would like to have the exact command ready.
Is it simply: 'gdb /usr/bin/i3', followed by a 'bt' ?

[Airblader]

From the crash dialog (the black rectangle) you can just press b and it will create the backtrace in /tmp. Of course you need to have gdb installed and you need to have i3 with debug symbols.

You can make sure your i3 has debug symbols by running file $(which i3) which should contain not stripped. If it stays that it's stripped you need to install debug symbols or compile i3 from source. But first let's find out whether you already have a stripped build.

[pdijksta]

Yes I went through the debugging guide on the i3 website before and I have a not stripped version.
I surely will manage to press the right button, then.

[endreszabo]

I second this issue. Happens every 8-10 times I change monitor layout with xrandr.

[Airblader]

Then it shouldn't be too difficult for somebody to provide a backtrace.

[epitheton]

The same issue here:
i3 --version
i3 version 4.12 (2016-03-06, branch "4.12") © 2009 Michael Stapelberg and contributors

(gdb) bt
#0  0x00007feb32be3550 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007feb35688150 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007feb35689ee9 in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x000055c679946814 in handle_signal (sig=<optimized out>, info=<optimized out>, data=<optimized out>) at ../i3-wm-4.12/src/sighandler.c:303
#4  <signal handler called>
#5  workspace_update_urgent_flag (ws=0x0) at ../i3-wm-4.12/src/workspace.c:795
#6  0x000055c67994ae1c in tree_close_internal (con=0x55c67af86d20, kill_window=kill_window@entry=DONT_KILL_WINDOW, dont_kill_parent=dont_kill_parent@entry=true, force_set_focus=force_set_focus@entry=false) at ../i3-wm-4.12/src/tree.c:208
#7  0x000055c67991b42d in randr_query_outputs () at ../i3-wm-4.12/src/randr.c:786
#8  0x000055c67993c876 in handle_screen_change (e=0x55c67afbc2b0) at ../i3-wm-4.12/src/handlers.c:462
#9  handle_event (type=<optimized out>, event=0x55c67afbc2b0) at ../i3-wm-4.12/src/handlers.c:1379
#10 0x000055c679924cdc in xcb_check_cb (loop=<optimized out>, w=<optimized out>, revents=<optimized out>) at ../i3-wm-4.12/src/main.c:133
#11 0x00007feb33540443 in ev_invoke_pending () from /usr/lib/x86_64-linux-gnu/libev.so.4
#12 0x00007feb33543aae in ev_run () from /usr/lib/x86_64-linux-gnu/libev.so.4
#13 0x000055c679914b4d in ev_loop (flags=0, loop=<optimized out>) at /usr/include/ev.h:835
#14 main (argc=<optimized out>, argv=<optimized out>) at ../i3-wm-4.12/src/main.c:882

[Airblader]

Thanks! Can you try whether PR #2522 would fix this?

[Airblader]

Can anybody test the PR? Otherwise I'm inclined to close this issue in favor of the PR until somebody says that it isn't fixed.

[endreszabo]

While I had this problem pretty often, it seems to be disappeared with i3 running with elevated debug settings. :weird: I personally did nothing else besides increasing of log levels.

[Airblader]

That's called a Heisenbug. :-) Race conditions in nature can disappear when you use debugging since debugging usually means a slight performance penalty. In the case of i3 it's not enough to be noticeable for the user, but can have this effect.

Can you revert the debug settings and run with the PR above instead? If it still doesn't come back I'd say the PR fixed it.

[pdijksta]

It did not happen again since the release of 4.13. Thank you.

[nmschulte]

I believe I am experiencing this issue as well; when moving the focus from one X11 output to another, a small black rectangle (say, 80 x 60 pixels?) flashes near the top left corner of the output losing focus.

I am running an interim build of next and was about to recompile, but I can test w/ this build if needed.

nmschulte@desmas-l:~/src/i3$ i3 --moreversion 2>&- || i3 --version
Binary i3 version:  4.13-12-g2ff3d9d (2016-11-16, branch "next") © 2009 Michael Stapelberg and contributors
Running i3 version: 4.13-12-g2ff3d9d (2016-11-16, branch "next") (pid 1870)
Loaded i3 config: /home/nmschulte/.config/i3/config (Last modified: Thu 08 Dec 2016 05:30:53 PM CST, 426833 seconds ago)

The i3 binary you just called: /home/nmschulte/.local/bin/i3
The i3 binary you are running: i3

---

I see this is closed now; I will follow up re: latest next build (#2522 fix) this evening, for clarity.

[nmschulte]

@Airblader, I am running i3 version 4.13-28-g8d739b7 (2016-12-09, branch "next") which if I'm not mistaken incorporates #2522 mentioned above; it doesn't seem to have resolved the issue for me.

Here is a video and a frame of that video showing the small black rectangle I see in the upper left when the focus leaves a display. In the video I switch between keyboard/mouse and the behavior persists.

flicker.mkv.zip

Occasionally when switching focus across outputs, in addition to the black rectangle, the output may "flicker," the "whole screen goes black" sometimes and others the whole screen just seems to flash a strangely artifacted version of what should be displayed and then quickly goes back to what should be displayed (in the same time period as the little black box; as though they're obv. related).

I want to note that lately (as of this week, but after I've been experiencing this black box issue), I am getting lots of strange issues w/ CPU locks and other weird kernel issues related to the i915/video driver. I don't think it's related, but I thought it worth mentioning.

[Airblader]

@nmschulte What you're seeing is something different, that's not the i3 crash dialog. I'm not too convinced this is an i3 issue, but can you please open it as a new issue for now?

[Airblader]

and other weird kernel issues related to the i915/video driver. I don't think it's related, but I thought it worth mentioning.

I wouldn't be so sure. :-)

[nmschulte]

What you're seeing is something different, that's not the i3 crash dialog.

I concur; I wasn't certain this was the same "black rectangle" or even the same kind of "xrandr ... switch displays." I'm happy for now; the configuration/installation on this system is a bit horked in other regards too. Unless you're interested in tracking down the issue for the issue's sake, I plan to re-install/configure this system in the near future in hopes of resolving or at least clarifying the issue (meaning, I may not be able to reproduce it soon).