Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Tue, Apr 18, 2017 at 4:08 AM, Michel Dänzer  wrote:
> On 18/04/17 11:55 AM, Luke Kenneth Casson Leighton wrote:
>> On Tue, Apr 18, 2017 at 3:27 AM, Michel Dänzer  wrote:
>>
 far from being 100% reproducible when resizing glxgears under fvwm2
 with DRI2, glxgears freezing is now 100% *un*reproducible.
>>>
>>> Please attach the Xorg log file.
>
> [...]
>
>> [   274.721] xorg-server 2:1.19.0-2.0nosystemd1 
>> (https://www.debian.org/support)
>
> The "nosystemd1" suggests that your xserver-xorg-core package isn't from
> Debian.

 it is... it's a modified recompiled version that is exactly identical
to debian, with the sole exception being that its compile-time options
are modified to include "--without-systemd" in the configure phase.

> Please report wherever you got it from that this support URL is
> misleading.
>
> The symptoms you're describing match a known bug in Xorg 1.19.0.

  ah ha!  at last!  dang was that hard to find someone who knows what
the underlying issue is.

> Please
> upgrade to 1.19.1 or newer.

 will do.

 l.

Bug#848895: Chromium freezes randomly

[Michel Dänzer]

On 18/04/17 11:55 AM, Luke Kenneth Casson Leighton wrote:
> On Tue, Apr 18, 2017 at 3:27 AM, Michel Dänzer  wrote:
> 
>>> far from being 100% reproducible when resizing glxgears under fvwm2
>>> with DRI2, glxgears freezing is now 100% *un*reproducible.
>>
>> Please attach the Xorg log file.

[...]

> [   274.721] xorg-server 2:1.19.0-2.0nosystemd1 
> (https://www.debian.org/support) 

The "nosystemd1" suggests that your xserver-xorg-core package isn't from
Debian. Please report wherever you got it from that this support URL is
misleading.

The symptoms you're describing match a known bug in Xorg 1.19.0. Please
upgrade to 1.19.1 or newer.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Tue, Apr 18, 2017 at 3:27 AM, Michel Dänzer  wrote:

>> far from being 100% reproducible when resizing glxgears under fvwm2
>> with DRI2, glxgears freezing is now 100% *un*reproducible.
>
> Please attach the Xorg log file.

 not too much to see, here, michel (yes it really is only 58 lines
long).  also including cat /proc/version and relevant section from
xorg.conf


lkcl@fizzy:/etc/X11$ cat /proc/version
Linux version 4.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc
version 6.3.0 20170124 (Debian 6.3.0-5) ) #1 SMP Debian 4.9.6-3
(2017-01-28)


Section "Device"
Identifier  "Intel Graphics"
Driver  "intel"
BusID   "PCI:0:2:0"
#Driver  "nvidia"
#BusID   "PCI:1:0:0"
#Option "SwapBuffersWait"   "false"
Option "AccelMethod""sna"
Option "TearFree"   "true"
Option  "DRI"   "3"
EndSection
[   274.305] 
X.Org X Server 1.19.0
Release Date: 2016-11-15
[   274.383] X Protocol Version 11, Revision 0
[   274.428] Build Operating System: Linux 4.8.10+ x86_64 Debian
[   274.483] Current Operating System: Linux fizzy 4.7.8lkcl #1 SMP Sun Dec 11 00:13:10 GMT 2016 x86_64
[   274.534] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.7.8lkcl root=/dev/mapper/pc-root ro quiet rcutree.rcu_idle_gp_delay=1
[   274.676] Build Date: 25 November 2016  03:55:18AM
[   274.721] xorg-server 2:1.19.0-2.0nosystemd1 (https://www.debian.org/support) 
[   274.765] Current version of pixman: 0.33.6
[   274.815] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[   274.855] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   275.250] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 12 00:03:16 2016
[   275.600] (==) Using config file: "/etc/X11/xorg.conf"
[   275.644] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   275.982] (==) ServerLayout "X.org Configured"
[   276.013] (**) |-->Screen "Screen0" (0)
[   276.043] (**) |   |-->Monitor "Monitor0"
[   276.074] (**) |   |-->Device "Intel Graphics"
[   276.103] (**) |-->Input Device "Mouse0"
[   276.134] (==) Automatically adding devices
[   276.164] (==) Automatically enabling devices
[   276.194] (==) Automatically adding GPU devices
[   276.225] (==) Max clients allowed: 256, resource mask: 0x1f
[   276.286] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   276.318] 	Entry deleted from font path.
[   276.481] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   276.511] 	Entry deleted from font path.
[   276.645] (**) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins,
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins
[   276.674] (**) ModulePath set to "/usr/lib/xorg/modules"
[   276.705] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[   276.734] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[   276.765] (WW) Disabling Mouse0
[   276.795] (II) Loader magic: 0x55f4e523cd40
[   276.826] (II) Module ABI versions:
[   276.856] 	X.Org ANSI C Emulation: 0.4
[   276.887] 	X.Org Video Driver: 23.0
[   276.917] 	X.Org XInput driver : 24.1
[   276.947] 	X.Org Server Extension : 10.0
[   277.386] (II) xfree86: Adding drm device (/dev/dri/card0)

Bug#848895: Chromium freezes randomly

[Michel Dänzer]

On 17/04/17 11:38 PM, Luke Kenneth Casson Leighton wrote:
> ok so i ended up with an unancipated reboot, which meant i had an
> opportunity to test DRI3 and since setting Option DRI "3" in
> xorg.conf i have *not* encountered a *single* lock-up, not with
> chromium, nor glxgears, nor openscad.
> 
> far from being 100% reproducible when resizing glxgears under fvwm2
> with DRI2, glxgears freezing is now 100% *un*reproducible.

Please attach the Xorg log file.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

ok so i ended up with an unancipated reboot, which meant i had an
opportunity to test DRI3 and since setting Option DRI "3" in
xorg.conf i have *not* encountered a *single* lock-up, not with
chromium, nor glxgears, nor openscad.

far from being 100% reproducible when resizing glxgears under fvwm2
with DRI2, glxgears freezing is now 100% *un*reproducible.

so there is definitely a case to be said that this is a mesa / x11
bug, *not* an application-specific bug.

does anyone know how to move bugs to a different package?

l.

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

ok i've raised this directly upstream with the mesa-dev team on
freedesktop.org and also done a little investigation, and found that
the processes are hanging waiting in a poll in libxcb.  the mesa-dev
team asked everyone who is affected *AND NOT* affected to report which
version of DRI is being used in their xorg.conf file (2 or 3) and also
which version of mesa is installed.

if that information could be sent here to 848895 then i can refer the
mesa-dev team to this bugreport.

i'm using DRI2 and mesa 13.0.6

btw if someone familiar with the debian bugtracker system could also
add the magic "control affects openscad" to this bugreport that would
be great.

l.

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

ha, that's very interesting: since starting the chat with my friend on
facebook (a developer in china) for about 90 minutes i have had
*three* lockups (each time recoverable with ctrl-alt-f1, ctrl-alt-f7).
one in particular the cursor moved off-screen for a fraction of a
second and back again (which is enough to cause fvwm to move very
rapidly from one virtual desktop to the next, requesting a complete
refresh obviously)

now, it *happened* that, at the exact same time, chromium was again
hogging CPU resources.  it would appear that the increased CPU usage
is the "vulnerable to lock-up" time.

hmmm :)

l.

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

haaa!  finally... after waiting for well over a week, at last!  the
bug *did* in fact reoccur.
just to make sure we're on the right page this is from the chrome://version

Chromium 56.0.2924.76 (Developer Build) built on Debian 9.0, running
on Debian 7.4 (64-bit)
Revision 314da7cc1e56fc9fa9271bac2b029922feb4b6f2

now, here's the circumstances:

* i was using facebook "chat" web variant (don't tell no-one in the
software libre world that, ok? :)
* CPU usage climbed *really* high - 3 processes each hit around 20%
and the CPU speed had to jump to around 2ghz to cope (fans came up)
* after flipping to a separate screen (i use fvwm) and returning
ta-d, freeze!

so whatever has been added that "fixes" the problem does NOT actually
fix the *ACTUAL* underlying race-condition / problem... it just avoids
*most* circumstances where it occurs... but not all.

l.

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

On Thu, Feb 23, 2017 at 9:41 PM, Ximin Luo  wrote:
> Luke Kenneth Casson Leighton:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=87
>>
>> 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.
>>
>> [..]
>
> Hi,
>
> I am not sure if primus is the problem. I don't have it installed.

 primus is an example of another application, like the many other
applications, where this underlying bug occurs for reasons as yet
unresolved.  we may therefore logically deduce that it's not a
chromium bug *per se* but is something to do with the dependencies
and/or interaction with the dependencies.

 the fact that running glxgears (or in fact *any* application -
openscad, vlc, *anything*) under optirun results pretty much
immediately (i.e. within seconds or minutes) in this bug being
reproduced is itself fascinating and also a useful setup for working
out what the hell is going on.

> In fact when I had the bug (on chromium 55.0.2883.75-6) I was using the free 
> nouveau drivers, not the nvidia drivers.

 from scanning the various responses it seems not to matter precisely
which underlying GPU hardware is used.  you're using nvidia, or
nouveau, others have reported different GPUs: it's not the GPU
*itself* which is the problem.


> I am now using the nvidia drivers with the same chromium version, and I have 
> not seen the bug for a few days. But if you do see it with nvidia drivers, 
> then something else must be the actual problem.

 it's not chromium itself that is the problem.  i can run "optirun
glxgears" then move / resize the window and it freezes.  therefore we
*know* that it's going to reoccur with chromium.

> I haven't yet tried 56.0.2924.76-4 that Michael says is fixed. BTW he has 
> closed the bug report #848895, I did not get a notification about this and I 
> only noticed when visiting the bug report web page. If any of you can 
> reproduce the bug with version 56.0.2924.76-4 please let us know so we can 
> re-open the bug.

prediction with 95% confidence: you'll need to reopen the bug.  the
remaining 5%, if it *has* been "fixed" with some form of workaround,
it should be very well documented *exactly* how, so that other
software can deploy the exact same "fix".  also the xorg team can be
alerted as there might be something that they can do which stops this
(endemic) bug from affecting other applications.

remember it's *not* just chromium that's affected.


 root@fizzy:/home/lkcl# apt-get install chromium
Reading package lists... Done
Building dependency tree
Reading state information... Done
chromium is already the newest version (55.0.2883.75-6).

so it's not hit debian/testing yet.  i'll wait another week until it does.

l.

Bug#848895: Chromium freezes randomly

[Ximin Luo]

Luke Kenneth Casson Leighton:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=87
> 
> 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.
> 
> [..]

Hi,

I am not sure if primus is the problem. I don't have it installed. In fact when 
I had the bug (on chromium 55.0.2883.75-6) I was using the free nouveau 
drivers, not the nvidia drivers.

I am now using the nvidia drivers with the same chromium version, and I have 
not seen the bug for a few days. But if you do see it with nvidia drivers, then 
something else must be the actual problem.

I haven't yet tried 56.0.2924.76-4 that Michael says is fixed. BTW he has 
closed the bug report #848895, I did not get a notification about this and I 
only noticed when visiting the bug report web page. If any of you can reproduce 
the bug with version 56.0.2924.76-4 please let us know so we can re-open the 
bug.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

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

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 (surprise!) 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.

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

btw fyi https://bugs.chromium.org/p/chromium/issues/detail?id=675411

i noted a vast and i mean constant monotonous barely-tolerable number
of gpu freezing errors when operating inside of china.  i therefore
suspect that this is a race condition between networking code and the
gpu code.

l.

Bug#848895: Chromium freezes randomly

[Luke Kenneth Casson Leighton]

ah ha!  when i did the latest "kill" i got this:

 [11121:11121:0207/112924:ERROR:gpu_process_transport_factory.cc(844)]
Lost UI shared context.

Bug#848895: Chromium freezes randomly

[Ximin Luo]

Ximin Luo:
> Control: affects -1 + vlc mpv gnome-mpv baka-mplayer
> 
> (I am using a personal package of baka-mplayer that I built for #813591 but 
> it's doesn't follow Debian policy in some areas so I can't upload it yet.)
> 
> Ximin Luo:
>> [..]
>>
>> A shorter workaround:
>>
>> $ pkill -f 'chromium --type=gpu-process'
>>
> 
> Sometimes the process is not called "chromimum" but like /proc/self/exe or 
> something, so it's more reliable to do
> 
> $ pkill -f 'type=gpu-process'
> 
> but sometimes even this doesn't work because (somehow) the start of the 
> cmdline gets messed up and a few characters at the start get chomped.
> 
> Another workaround is to switch to a non-X virtual terminal and then switch 
> back again, e.g. ctrl-alt-f1 ctrl-alt-f7, which is probably quicker than 
> doing pkill.
> 
> I've observed the random hanging behaviour for other media players as well 
> (VLC, mpv, baka-mplayer, gnome-mpv). With these programs there is no 
> "type=gpu-process" subprocess to kill, but the ctrl-alt-f1 ctrl-alt-f7 trick 
> does work to "unfreeze" the program.
> 
> So this is probably not chromium-specific, but related to the way in which 
> these programs use graphics through X. However, I don't know the best package 
> to re-assign this bug to, so I'll leave it for chromium.
> 

Hey guys, the Debian BTS doesn't CC previous commenters by default, so please 
remember to keep everyone CC'd so we don't missing out on updates.

(I see that Vassil had also figured out the ctrl-alt-f1 ctrl-alt-f7 trick in 
the meantime.)

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#848895: Chromium freezes randomly

[Douglas A. Augusto]

On Sat, 21 Jan 2017 16:56:40 -0500 Michael Gilbert  wrote:
  
> Is this #801128?

I don't think so since I couldn't reproduce the bug the way the reporter
described it (via octave-cli).


Best,

-- 
Douglas A. Augusto


signature.asc
Description: PGP signature

Bug#848895: Chromium freezes randomly

[Michael Gilbert]

Douglas A. Augusto wrote:
> This trick works for me too. By the way, I just found out that the reported
> bug also affects octave-gui (4.0.3-2+b2), which randomly freezes just like
> chromium. And the exact same trick you described also works with
> octave.

Is this #801128?

Best wishes,
Mike

Bug#848895: Chromium freezes randomly

[Michael Gilbert]

control: tag -1 moreinfo

Since this also effects upstream google-chrome, and other applications
like octave-gui, it may be more likely a mesa, X11, or gpu driver bug.
For those willing to dig in, try rolling some of the underlying
packages back a few months.

Best wishes,
Mike

Bug#848895: Chromium freezes randomly

[Michael Stummvoll]

Package: chromium
Version: 55.0.2883.75-2
Severity: important

Dear Maintainers, 

Chromium randomly freezes for me frequently. This means the chromium
window is completely unresponsive and the process can only be
terminated using the SIGTERM signal or the xkill command. I can't see
any patterns regarding the websites or runtimes where it happens, it
seems to be completely random to me. Sometimes the Window becomes
unresponsive while I am interacting with chromium, sometimes it seems
to happen while the browser window is in the background for a few
minutes.

Theres no output on the terminal when the freeze happens, however
chromium prints out these two lines on startup (not sure if this is
relevant)

> [21539:21539:1220/121304:ERROR:sandbox_linux.cc(343)] InitializeSandbox() 
> called with multiple threads in process gpu-process.
> libpng warning: iCCP: known incorrect sRGB profile

Sorry for not beeing able to provide more details. If you need more
informations please tell me how to obtain them and I will attach them.

Kind Regards,
Michael Stummvoll