[Pkg-chromium-maint] Bug#848895: Chromium freezes randomly

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Feb 22 14:50:45 UTC 2017


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855557

now ain't that fascinating.  optirun combined with fvwm2 is a
sure-fire extremely fast and 100% *guaranteed* way to repro this
"freezing but you can ctrl-alt-f1 then ctrl-alt-f7 and it miraculously
all works whoopidoo" problem.

primus (and optirun) is a headless gpu thingy where you have a main
CPU/GPU which actually does the screen writing, then you have a
*second* xorg server running (this time into a framebuffer) which you
have a *second* GPU writing to, where OpenGL is told to use the
*second* GPU's acceleration libraries, then primus takes care of
dropping the resultant frame(s) into the *first* xorg's screenspace.

fascinatingly it's very very easy to make primus/optirun "hang" under
fvwm2: all you need to do is resize the window: that results in a
wireframe, then primus goes into a *permanent* loop "primus: warning:
dropping a frame to avoid deadlock"

which is clearly where chromium is obviously going wrong: it's *not*
doing the required "frame dropping" and is (surpriiiiise!) ending up
in deadlock.

now, the hardware shouldn't *BE* getting into deadlock in the first
place, and chromium shouldn't *BE* relying on the hardware to quotes
get itself out of deadlock quotes, but that's beside the point.

this all seems to be, then, a series of overlapping cross-project
errors, each inter-related.  hardware shouldn't *be* failing but it
is.  xorg shouldn't *be* deadlocking due to those hardware-related
errors but it is.  chromium and other programs shouldn't *be*
deadlocking because xorg is deadlocking... but they are.

l.



More information about the Pkg-chromium-maint mailing list