Issue metadata
Sign in to add a comment
|
Chrome address bar & tabs turn black, GL rendering crashes with GL_OUT_OF_MEMORY and window does not recover
Reported by
fi...@zaidan.de,
Oct 8
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce the problem: 1. Open some tabs 2. Do some stuff for some minutes / hours - window resizing may have an effect, not sure 3. Chrome window will start to render black tabs and menu bars: https://i.stack.imgur.com/HKJcE.gif What is the expected behavior? What went wrong? Address bar and tabs turn black. Hover is possible and some parts show up while mouse hover, but disappear after mouse hover. Window does not recover, but moving tabs to a new window is possible. The issue will happen again after some time. GPU log contains some errors, like GL_OUT_OF_MEMORY and rendering warnings like "texture bound to texture unit 1 is not renderable". Crashed report ID: How much crashed? Whole browser Is it a problem with a plugin? N/A Did this work before? Yes Issue started happening in the last 6-12 months Chrome version: 69.0.3497.100 Channel: stable OS Version: 4.18.12-arch1-1-ARCH Flash Version: Device: Thinkpad P70 with Quadro M4000M User in comment 1 describes same issue and has one of the rendering warnings attached to this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=611589#c1 This issue could be Nvidia Quadro / Quadro M4000M related and is not related to a specific Linux distribution: https://askubuntu.com/questions/1073082/chrome-address-bar-tabs-turn-black The log contains a GPU sandbox issue.
,
Oct 15
,
Oct 16
Same here: Ubuntu 16.04.5 LTS x86_64, Nvidia GTX 1050, Nouveax Driver, Chrome 69.0.3497.100 (Official Build) (64-bit)
,
Oct 19
This seems similar to some other Linux issues, like issue 893750 and maybe issue 606152. Not sure if it's a dupe though, so I'll leave it open.
,
Nov 8
I have the similar issue of GL_OUT_OF_MEMORY while running chromium on a device with limited memory.
,
Nov 17
I have the same issue, on a system with 64GB of memory & GTX960. There is 1 instance of [.BrowserWorker-0x55df13e0d0f0]GL ERROR :GL_OUT_OF_MEMORY : GLES2DecoderImpl::DoBindTexImage2DCHROMIUM: <- error from previous GL command the chrome://gpu log is filled with messages like [5434:5434:1117/062454.963032:ERROR:gl_surface_presentation_helper.cc(237)] : GetVSyncParametersIfAvailable() failed! and [.BrowserCompositor-0x55df15464410]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
,
Nov 19
I proposed this before: should we just exit GPU process and relaunch it when we encounter a OUT_OF_MEM error? At that point, Chrome GPU process enters a dangerous zone. I don't think our code handles OUT_OF_MEM well, so many commands could fail and leak error to the next.
,
Nov 19
,
Nov 19
Per offline discussion with piman, let's apply EXIT_ON_CONTEXT_LOST on Linux also (currently it's applied on Windows). This is the simplest way to get Chrome on Linux to recover from OUT_OF_MEMORY situation, although that's still not the best thing to do.
,
Nov 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1dc06d62d4899eff5ae4a7be7c96daaee6f9dc84 commit 1dc06d62d4899eff5ae4a7be7c96daaee6f9dc84 Author: Zhenyao Mo <zmo@chromium.org> Date: Tue Nov 20 00:20:04 2018 Exit GPU process on context lost on Linux. Some Linux drivers do not seem to recover well after OUT_OF_MEM and context lost. BUG= 893117 TEST=bots R=piman@chromium.org Change-Id: I55faefe2d631f3a682dd0b441d2a835836b792a6 Reviewed-on: https://chromium-review.googlesource.com/c/1343102 Reviewed-by: Antoine Labour <piman@chromium.org> Commit-Queue: Zhenyao Mo <zmo@chromium.org> Cr-Commit-Position: refs/heads/master@{#609522} [modify] https://crrev.com/1dc06d62d4899eff5ae4a7be7c96daaee6f9dc84/gpu/config/gpu_driver_bug_list.json
,
Nov 20
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by m...@theputnams.net
, Oct 12