Chromium "freezing" every interaction with i3.

[ljrk0]

i3 version: i3 version 4.10.2-171-ga4fab76 (2015-05-25, branch "makepkg")
chromium version: tested dev, continuous and stable
OS: Arch
Compositor: compton (yes, I know, not supported, but I'm not sure whether it relates to this problem :P)
Debug log: http://logs.i3wm.org/logs/5700239927279616.bz2

How to reproduce:

Switch often and fast between a "Chromium-workspace" and a "non-Chromium-workspace" (eg. the terminal). Seems only to happen when one is about to do serious work ^^.
Bug occures only on switching workspace and the frozen state will only show the Chromium workspace, not the other one.

Description:

One can still interact with the windows but one does not see any reaction just the mousepointer changing, the fan loudness changing (when one blindly quits a hungry application) or just blindly executing "reboot" in terminal.

Changing to the tty and back just results in the whole screen now being completely black/grey. One can still interact but does not even see the "frozen" chromium window.

Restarting i3 in place or killing any apps does not solve the problem.

I hope I expressed it in a understandable way, it seems to be a really weird bug. It does not happen on LXQt + Compton, not on Plasma or awesome, but it also does not happen with Firefox. So the problem cannot only be i3, nor only be Chromium nor compton.

[Airblader]

With Chrome (43.0.2357.73 beta) I don't seem to be able to reproduce this. Even a for i in $(seq 1 100); do i3-msg "workspace back_and_forth" ; done didn't break anything. Haven't looked at the provided log file yet.

[ljrk0]

Hm, I'm not sure what's causing this. Xorg.0.log has no messages in it since it's startup.

[Airblader]

I also tried it with Chromium (42.0.2311.135) now and can't repro it there either.

The log file covers 22 minutes and is ober 26k lines long. It could be helpful if you could upload a log file where you boot your system, instantly reproduce this and then take the log.

Unless someone als can repro it, maybe you can also try an older i3 to see if the problem exists there as well. If not, you can run a git bisect.

[simonnagl]

I also tried with Chromium 43.0.2357.65 and the script posted by @Airblader. I cannot reproduce the issue.

[ljrk0]

Hm, I tried your script and it didn't fail either. But when I started vim (which relates to the "serious work part") it did fail, after I focusing vim while executing the script. Only a shot in the dark though.

This log only covers a few minutes (first executed script with only terminal + Chromium, then with vim in terminal + Chromium, which froze it):
http://logs.i3wm.org/logs/5071662873575424.bz2

The problem existed in a build I ran ~ a month ago. I updated to the latest version to see if it was fixed there but forgot to note the old build version.

EDIT: It's not very common though. Sometimes I could boot and ran the script even with 1000 instead of 100 and it didnt fail for several times.

[Airblader]

I still can't repro it using vim, unfortunately. I also can't see anything suspicious in the logs. Maybe running a xtrace on Chromium would reveal more? It sounds like a bad case of race condition.

by the way, just to be sure: so i3 itself works just fine and only Chromium is broken, right?

[ljrk0]

It's difficult to figure it out as only the combination Chromium + i3 ain't working. Chromium + anything else works, Anything else + i3 works, too. I could post this to the Chromium bugtracker too but what makes me suspicious is that killing Chromium still doesn't solve the problem. Maybe the root of the problem is a freezing Chromium but i3 doesn't handle it properly.

I can't remember any problem before January at least, but since then both, Chromium and i3 received many updates. I've got a second machine here and will try it on this one, too. Xtrace might be a good idea too. Bisect is a bit difficult because my hardware is rather old that even rebuilding i3 takes some time. If the issue persists I still will try that ofcourse – but there's still the problem of missing the relevant commit as there's no 100%-way of crashing the setup, it sometimes happens, and sometimes not.

[stapelberg]

Bisect is a bit difficult because my hardware is rather old that even rebuilding i3 takes some time

Even on my 7-year old ThinkPad X200, building i3 just takes a couple of seconds. Bisect converges very quickly, so this might be more feasible than you think :).

[ljrk0]

Hmm, it takes a couple of minutes for me, not much, but tracing back still requires some rebuilds. But the bigger doubt for me is that I just ran the script with 1 to 1000 and it crashed after the 15th attempt... . So I stilly might miss the commit, which would be sad ^^. Currently testing (xtrace on Chromium) for ~1h with nothing bad happening. Before it sometimes happened almost instantly. It really is strange

[Airblader]

Currently testing (xtrace on Chromium) for ~1h with nothing bad happening

Well, with some bad luck, xtracing it makes it slow enough to eliminate the race condition.

[ljrk0]

Hah, just got it ;-). Only a minute after writing this...
The beginning is the standard stuff I get everytime starting chromium, nothing special^^. I'm not sure whether the last lines are caused by me doing "i3-msg exit" or by the freeze. I think the former as I said that I can still interact with the program – just not seing any reaction.
The last resort for me is doing bisect, but will do so.

Chromium log (xtrace was empty, no messages EDIT: see later comments)

[32052:32052:0525/175715:ERROR:background_mode_manager_aura.cc(14)] Not implemented reached in virtual void BackgroundModeManager::EnableLaunchOnStartup(bool)
[10:10:0525/175722:ERROR:resource_request_policy.cc(57)] Denying load of chrome-extension://apdfllckaahabafndbhieahigkjlhalf/page_embed_script.js from hosted app.
[10:10:0525/175724:ERROR:resource_request_policy.cc(57)] Denying load of chrome-extension://apdfllckaahabafndbhieahigkjlhalf/page_embed_script.js from hosted app.
[32052:32322:0525/175733:ERROR:get_updates_processor.cc(243)] PostClientToServerMessage() failed during GetUpdates
[10:10:0525/175733:ERROR:resource_request_policy.cc(57)] Denying load of chrome-extension://apdfllckaahabafndbhieahigkjlhalf/page_embed_script.js from hosted app.
[32052:32085:0525/175738:ERROR:channel.cc(300)] RawChannel read error (connection broken)
[155:156:0525/180201:ERROR:channel.cc(300)] RawChannel read error (connection broken)
[10:10:0525/180233:ERROR:resource_request_policy.cc(57)] Denying load of chrome-extension://apdfllckaahabafndbhieahigkjlhalf/page_embed_script.js from hosted app.
Fontconfig error: Cannot load default config file
[560:561:0525/184428:ERROR:channel.cc(300)] RawChannel read error (connection broken)
[32052:32052:0525/184902:ERROR:chrome_browser_main_extra_parts_x11.cc(56)] X IO error received (X server probably went away)
[32090:32090:0525/184902:ERROR:x11_util.cc(82)] X IO error received (X server probably went away)

[ljrk0]

Ok, I just checked out the code at 69dd8ce (UPDATE: and the error recurs,) but I'm 99% sure that the issue did not occure back then. So the issue is probably caused by Chromium in a later revision (I won't build that tho^^ my poor intel Centrino laptop just howled so much (while executing the test script), I almost felt pity for it...). I tested via the posted script but just with 15000 to make things super sure.

But still, I think a Chromium-crash / freeze should not cause a whole session to break down. If anyone has any hints on what logs I could supply or how to help in any other way, I will do so.
Sadly, there were no errors reported by Chromium that could relate to the issue.

[ljrk0]

Ok, just got an xtrace, made the fault of more or less blindly following a instruction with "-display" which chromium does not support. Using DISPLAY ofcourse worked.
Here you go:
https://gist.github.com/LeonardKoenig/5b530a861c13a0df00ab

[Airblader]

Ok, I just checked out the code at 69dd8ce and I'm 99% sure that the issue did not occure back than. So the issue is probably caused by Chromium in a later revision

Sorry, I don't follow – why does this mean that Chromium causes the issue?
Seems to me you now have a bad and a good commit – and with that, you can start a bisect. It will only take 9 iterations at worst, that should be doable, no?

[ljrk0]

Oh, just realized the comment was incomplete. I mean to say:
Just checked out 69dd8ce and built it, issue still occuring though it did not occure back then (end of december), so the issue should be an update of Chromium in between

[Airblader]

Oh, okay. I'm not convinced that this puts i3 out of blame, though. For one, race conditions can start popping up for the weirdest (and unrelated) reasons, but also other window managers not having this problem could just mean that an update of Chromium surfaced this problem in i3. We should keep treating this as a potential bug in i3.

[ljrk0]

Hm, this could be like this, too. I just looked onto the xtrace and literally do not understand anything – ok, I know what opcodes are etc, but have no clue what these mean... . Much hex is dumped and I fear it is binary and of no value at all :/

[ljrk0]

I attached gdb to Chromium but nothing. Just notifications like new thread, new opened tab. No errors at all.

[ljrk0]

I think I can confirm that this sadly is a compton problem. Without compton I could run 100.000 switches without anything happening. Will see to that though. An as I know you don't support compositors this probably can be closed. Maybe the thing did not happen on LXQt+compton because I could not switch that fast on LXQt as on i3wm.

[ljrk0]

After killing compton when freezed I shortly see flickering of the workspace again, like it should be, but then i3wm exits. Why that?

[ljrk0]

This time i3 did not crash after compton got killed – confirming: compton is the issue. I'm still wondering why i3 crashed last time when I killed compton, but it works now for me.
Will "move" this to the compton issue tracker :P

[ljrk0]

Hm, small follow up:
Happened again and this time i3/X crashed again. I could not dump the log because i3 wasn't running anymore, but this is the Xorg.log:

[ 42681.045] (EE) 
[ 42681.045] (EE) Backtrace:
[ 42681.079] (EE) 0: /usr/lib/xorg-server/Xorg (OsLookupColor+0x119) [0x594a29]
[ 42681.080] (EE) 1: /usr/lib/libc.so.6 (__restore_rt+0x0) [0x7fb1c5c575af]
[ 42681.080] (EE) 2: /usr/lib/xorg-server/Xorg (AttendClient+0x8) [0x592948]
[ 42681.080] (EE) 3: /usr/lib/xorg-server/Xorg (SendShapeNotify+0x1ff8) [0x4d3a98]
[ 42681.081] (EE) 4: /usr/lib/xorg-server/Xorg (miSyncDestroyFence+0x59) [0x565e09]
[ 42681.081] (EE) 5: /usr/lib/xorg-server/Xorg (SendShapeNotify+0x2549) [0x4d4619]
[ 42681.081] (EE) 6: /usr/lib/xorg-server/Xorg (RegisterResourceName+0x232) [0x45bc12]
[ 42681.082] (EE) 7: /usr/lib/xorg-server/Xorg (FreeClientResources+0x6c) [0x45cafc]
[ 42681.082] (EE) 8: /usr/lib/xorg-server/Xorg (CloseDownClient+0x70) [0x437ee0]
[ 42681.083] (EE) 9: /usr/lib/xorg-server/Xorg (EstablishNewConnections+0xcd) [0x591e1d]
[ 42681.083] (EE) 10: /usr/lib/xorg-server/Xorg (ProcessWorkQueue+0x21) [0x43d9b1]
[ 42681.083] (EE) 11: /usr/lib/xorg-server/Xorg (WaitForSomething+0x88) [0x58d848]
[ 42681.084] (EE) 12: /usr/lib/xorg-server/Xorg (SendErrorToClient+0x111) [0x4388b1]
[ 42681.084] (EE) 13: /usr/lib/xorg-server/Xorg (remove_fs_handlers+0x41b) [0x43cbcb]
[ 42681.085] (EE) 14: /usr/lib/libc.so.6 (__libc_start_main+0xf0) [0x7fb1c5c44790]
[ 42681.086] (EE) 15: /usr/lib/xorg-server/Xorg (_start+0x29) [0x427039]
[ 42681.087] (EE) 16: ? (?+0x29) [0x29]
[ 42681.087] (EE) 
[ 42681.087] (EE) Segmentation fault at address 0x0
[ 42681.087] (EE) 
Fatal server error:
[ 42681.087] (EE) Caught signal 11 (Segmentation fault). Server aborting
[ 42681.087] (EE) 
[ 42681.087] (EE) 
Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 
[ 42681.087] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 42681.087] (EE) 
[ 42682.822] (EE) Server terminated with error (1). Closing log file.

If anyone has any idea what's that.

[stapelberg]

That’s a crash in your X server, not i3-related.

[ljrk0]

Ok, thanks. I just thought it was i3 because it only happened there. Turns out that compton – again :P – was the problematic part, though it's unclear (for me) whether the bug is in compton or in a X-lib it uses.

Thanks for any help and poiniting me in the right direction.

[KubaJastrz]

That's interesting. I've managed to run into the same problem as you @leonardkoenig. My first guess was compton too, but after few days running without it, it starts to happen again. Killing the frozen program and restarting works only for a while.

Not only for Chromium, but all blink-based (electron) programs and, surprisingly, Sublime Text 3 (3200) which is using gtk3.

Edit: ST3 was a false positive, it is running into some other problems.

[ohanf]

I am also having what I assume is the same issue. I do not run compton either. The problem only recently started happening and it seems to effect all chromium based applications as mentioned above. For me this is primarily Chrome, Discord and VS Code (which happen to be my 3 most used applications apart from uxrvt). I am not sure which logs would be helpful, and the bug does not seem to be very consistent, but if this is still being monitored I am happy to provide logs as needed.

[orestisfl]

Please open a new issue with as much information as possible.

[KubaJastrz]

The main thing I suspect is hardware acceleration having some troubles with certain gpu drivers that occur with blink-based software. I can post more once I investigate further.

[0o220]

@ohfill @KubaJastrz I've been having the exact same issue for the past 2–3 months (but never before then). For example, Chromium-based qutebrowser "froze" four times while I was writing this post, requiring a SIGKILL and restart. Slack behaves the same way (and they generally tend to freeze at the same time). I've been monitoring application-specific logs without finding any clues to the root cause. Very interested to hear about any progress made on this issue.

[orestisfl]

Very interested to hear about any progress made on this issue.

Zero progress on a 4 year old issue that was closed. Please open a new issue with as much information as possible.