After Mesa upgrades, Chrome won't show graphics

Bug #2020604 reported by Sam
96
This bug affects 16 people
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)
Invalid
Critical
Unassigned
Jammy
Invalid
Undecided
Unassigned
Lunar
Invalid
Undecided
Unassigned
mesa (Ubuntu)
Fix Released
Critical
Unassigned
Jammy
Fix Released
Undecided
Unassigned
Lunar
Invalid
Undecided
Unassigned

Bug Description

[Impact]
After patching Mesa with some driver updates, Chromium/Brave started seeing corrupt graphics. This was due to GPU acceleration being enabled in the browser by default now, and the old GPU shader cache is invalid in some ways and the browser is not able to recognize that the driver has changed, since the upstream version string hasn't changed. This is shown for instance with 'glxinfo -B' or under 'chrome:gpu' from the browser.

The fix is to make the upstream VERSION to have the full packaging version, this will then be used for the core profile version string as well.

[Test case]

- run stock jammy, install brave-browser from brave.com, launch brave-browser, check that 'brave://gpu' shows things are accelerated, then exit the browser

- enable proposed, install libgl1-mesa-dri et al

- launch brave-browser again, verify that gfx are not corrupted and brave://gpu is showing acceration being used

with the pulled update, graphics would be severely corrupted

[Where things could go wrong]
There could be apps that expect the Mesa version string to only contain a.b.c, and break in some ways when that's no longer the case.

--

After today's Ubuntu 22.04 Mesa upgrades many of our users reported problems viewing graphics when using Google Chrome (Stable).

The Mesa upgrades we installed were:

[UPGRADE] libegl-mesa0:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2
[UPGRADE] libegl1-mesa:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2
[UPGRADE] libgl1-mesa-dri:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2
[UPGRADE] libgl1-mesa-glx:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2
[UPGRADE] libglapi-mesa:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2
[UPGRADE] libglx-mesa0:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2
[UPGRADE] mesa-vulkan-drivers:amd64 22.2.5-0ubuntu0.1~22.04.1 -> 22.2.5-0ubuntu0.1~22.04.2

We documented the problem in AskUbuntu before we realized it was probably related to Mesa, so wanted to link to that report here:

https://askubuntu.com/questions/1469116/since-23-may-2023-ubuntu-22-04-mesa-updates-chrome-wont-display-website-graphi

There are several useful pointers and bypasses listed in that AskUbuntu link (one being to remove affected users' GPUCache directories, which does not destroy their profiles and seems to work in many but not all cases).

Not sure if this is an issue with Mesa or Chrome or specific machine graphics or an interaction between them.

description: updated
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Libera.chat.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/2020604/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
affects: ubuntu → mesa
Revision history for this message
George (george-labuschagne-gmail) wrote :

Hi all my users are also effected by this bug and cannot use Chrome at the moment.

Please let me know if you need any other info to get this resolved.

Revision history for this message
George (george-labuschagne-gmail) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mesa (Ubuntu):
status: New → Confirmed
Paul White (paulw2u)
affects: mesa → mesa (Ubuntu)
Changed in mesa (Ubuntu):
status: New → Confirmed
Revision history for this message
Lorenzo Buzzi (flinco) wrote (last edit ):

I confirm the issue on a desktop with Intel HD Graphics 530 (rev 06) (Core i7-6700 CPU).

At present time I found that it can be worked around in two ways:

1) Using the '--disable-gpu-driver-bug-workarounds' option:
# google-chrome-stable --disable-gpu-driver-bug-workarounds

2) Defining MESA_LOADER_DRIVER_OVERRIDE=i965 in the environment in which chrome is executed:
# MESA_LOADER_DRIVER_OVERRIDE=i965 google-chrome-stable

I can send any further information (or make any test) that can help you in fixing the issue.

PS: deleting the GPUCache and the ShaderCache folders did not work for me.

Revision history for this message
Shashi (iversion) wrote :

I confirm the issue on a ThinkPad T440

Intel® Core™ i5-4300U CPU @ 1.90GHz × 4
Mesa Intel® HD Graphics 4400 (HSW GT2)

As a workaround I have renamed GPUCache folder for both chrome and brave browser.

Revision history for this message
John Dydo (johndozzz) wrote :

--disable-gpu-driver-bug-workarounds did not work for me, but deleting GPUCache did. Keep in mind that GPUCache could be inside a profile folder like ~/.config/google-chrome/Profile 1/.

Revision history for this message
CoderGuy (alec-bickerton) wrote :

While it's obviously not a real fix, As I don't use chrome as my primary browser, simply regenerating my ~/.config/google-chrome/ directory resolved this issue. Others may not have this option.

Question 1 : What is it about the Mesa upgrade that kills chrome but not Firefox?
Question 2 : Is there a less nuclear fix than wiping the Chrome settings? e.g. Deleting just the ShaderCache or GrShaderCache directories?

description: updated
description: updated
Revision history for this message
Jesse (gammagames) wrote :

`rm -R ~/.config/google-chrome/Default/GPUCache` (and then restarting chrome) from the askubuntu post fixed it!

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

seems like this is a generic issue with chromium not being able to invalidate the gpucache when the GL_RENDERER string changes, which is every time Mesa is updated

affects: mesa (Ubuntu) → chromium-browser (Ubuntu)
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

also, hardware acceleration in chromium is not enabled by default AIUI, but it is enabled in the recent beta snap

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

and if you're using 3rd party chrome, there's little we can do about it

Revision history for this message
Nathan Teodosio (nteodosio) wrote :

Passing --disable-gpu would likely help here.

Hardware acceleration stuff can be seen in about://gpu.

At the moment we have hardware acceleration decoding, which as far as I can tell is not the issue here, in candidate/hwacc and edge/hwacc but that is focused at Intel.[1]

For the time being I think for Chromium snap we can just add a

  rm -r "$SNAP_USER_COMMON"/chromium/*/GPUCache

as a stop gap measure.

[1] https://discourse.ubuntu.com/t/chromium-hardware-accelerated-build-for-intel-based-platforms-available-for-beta-testing/35625/3

Revision history for this message
Nathan Teodosio (nteodosio) wrote :

Rebuilding with that proposed workaround.[1]

Again, reiterating #14, this will not affect Google Chrome, which we don't control, only Chromium.

[1] https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/commit/?id=81d10f4fc880eb76ec39b47e2776a5359dd5a7f0

Changed in chromium-browser (Ubuntu):
status: Confirmed → Fix Committed
Revision history for this message
Chris Hall (cmhallmi) wrote : Re: [Bug 2020604] Re: After mesa upgrades, Chrome won't show graphics

Disabling gpu solved the problem for both Brave, Brave-beta and Chrome.
Once I could get the browsers to open up and render text, it was than
possible to turn off hardware acceleration. Any idea if the mesa driver
problem will be addressed in the next update?

An ironic thing about the about://gpu url is that unless you disable the
gpu, it's not possible to even read  the url. A real chicken and egg
problem.

Chris Hall

On 5/26/23 4:13 AM, Nathan Teodosio wrote:
> Passing --disable-gpu would likely help here.
>
> Hardware acceleration stuff can be seen in about://gpu.
>
> At the moment we have hardware acceleration decoding, which as far as I
> can tell is not the issue here, in candidate/hwacc and edge/hwacc but
> that is focused at Intel.[1]
>
> For the time being I think for Chromium snap we can just add a
>
> rm -r "$SNAP_USER_COMMON"/chromium/*/GPUCache
>
> as a stop gap measure.
>
> [1] https://discourse.ubuntu.com/t/chromium-hardware-accelerated-build-
> for-intel-based-platforms-available-for-beta-testing/35625/3
>

Revision history for this message
Nathan Teodosio (nteodosio) wrote :

> Any idea if the mesa driver
> problem will be addressed in the next update?

Time will tell, if my reading of #12 is correct then this isn't really a
problem with Mesa but with upstream.

> An ironic thing about the about://gpu url is that unless you disable the
> gpu, it's not possible to even read  the url. A real chicken and egg
> problem.

One could do a blind

   Ctrl+L
   about:gpu<Enter>
   <Tab>
   <Space>

to get the report to clipboard, but you would never know that without
seeing the page. (:

That information isn't otherwise available even with
--enable-logging=stderr --v=1...

Jeremy Bícha (jbicha)
Changed in chromium-browser (Ubuntu):
importance: Undecided → High
tags: added: jammy regression-update
Changed in mesa (Ubuntu):
importance: Undecided → High
status: New → Triaged
Revision history for this message
Jeremy Bícha (jbicha) wrote :

I'm setting the importance to Critical per https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

Changed in mesa (Ubuntu):
importance: High → Critical
Changed in chromium-browser (Ubuntu):
importance: High → Critical
Revision history for this message
Nathan Teodosio (nteodosio) wrote (last edit ):

The workaround is available in candidate channel (currently only ready for amd64).

  snap refresh --candidate chromium

If someone could please verify the workaround, I can bump to stable.

Revision history for this message
Dave Chiluk (chiluk) wrote :

As I have multiple profiles, I chose to simply delete all Cache directories

$ find ~/.config/google-chrome \( -name "*Cache" \) | xargs -d '\n' -L 1 rm -rf

Revision history for this message
Mario Limonciello (superm1) wrote :

It seems a way that this may be avoided is for GL_RENDERER string to always be updated when mesa updates.

Revision history for this message
Chris Hall (cmhallmi) wrote :

Well, on one of my machines I installed Mesa from the kisak more stable
ppa ("turtle"), which is more up to date than mesa from the jammy
repository. I was able to re-enable hardware acceleration with no
problems. So there is something in the whole collection of mesa packages
that broke several chromium based browsers.

On 5/26/23 11:14 AM, Nathan Teodosio wrote:
>> Any idea if the mesa driver
>> problem will be addressed in the next update?
> Time will tell, if my reading of #12 is correct then this isn't really a
> problem with Mesa but with upstream.
>
>> An ironic thing about the about://gpu url is that unless you disable the
>> gpu, it's not possible to even read  the url. A real chicken and egg
>> problem.
> One could do a blind
>
> Ctrl+L
> about:gpu<Enter>
> <Tab>
> <Space>
>
> to get the report to clipboard, but you would never know that without
> seeing the page. (:
>
> That information isn't otherwise available even with
> --enable-logging=stderr --v=1...
>

summary: - After mesa upgrades, Chrome won't show graphics
+ After Mesa upgrades, Chrome won't show graphics
description: updated
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

I've got a proposed fix to mangle PACKAGE_VERSION to use the full packaging version instead of just upstream x.x.x. It's available now on ppa:tjaalton/test

To verify if that works, you'd need to run chrome/chromium with the current version in -updates first (...22.04.1), then update to the ppa version (22.04.3~ppa1) and see if it still works.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

oh well, chrome still segfaults on startup even with that one, although GL_RENDERER has changed now

Revision history for this message
Valentyna (valia0906) wrote (last edit ):

I`ve installed mesa update fom provided ppa and the promlem disappeared, but when I start Chrome at first time after mesa upgrade it works but till craches on log. Second time and after it it works and runs without crash in log.

Timo Aaltonen (tjaalton)
Changed in chromium-browser (Ubuntu Jammy):
status: New → Invalid
Changed in chromium-browser (Ubuntu Lunar):
status: New → Invalid
Timo Aaltonen (tjaalton)
description: updated
Revision history for this message
Nathan Teodosio (nteodosio) wrote :

For the lack of confirmation of #20 and since this is going to be addressed in Mesa itself, I'm removing the workaround I had added to Chromium.

Changed in chromium-browser (Ubuntu):
status: Fix Committed → Invalid
Revision history for this message
Mario Limonciello (superm1) wrote :

I believe the same thing can likely happen if llvm updates but mesa stays the same. Can you embed both into the string?

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

That's correct, but so far llvm updates have been done in tandem with mesa backports, so I'm not too worried about those this time.

The upstream solution should take that into account, though.

Revision history for this message
Steve Langasek (vorlon) wrote : Please test proposed package

Hello Sam, or anyone else affected,

Accepted mesa into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/mesa/22.2.5-0ubuntu0.1~22.04.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in mesa (Ubuntu Jammy):
status: New → Fix Committed
tags: added: verification-needed verification-needed-jammy
Revision history for this message
Sam (i41bktobiu5q-launchpadnet) wrote :

Thank you very much Steve (and Timo and everyone else that has helped). We will test it on a few systems this weekend.

Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (mesa/22.2.5-0ubuntu0.1~22.04.3)

All autopkgtests for the newly accepted mesa (22.2.5-0ubuntu0.1~22.04.3) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

gtk+3.0/3.24.33-1ubuntu2 (i386)
mutter/42.5-0ubuntu1 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#mesa

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Revision history for this message
Sam (i41bktobiu5q-launchpadnet) wrote :

Okay we'll wait for a later build.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

forget about those test failures, they're flaky by nature

Revision history for this message
Sam (i41bktobiu5q-launchpadnet) wrote :

OK just a question about pinning since we would prefer to minimize changes to user systems. When we follow the instructions from Steve's message on:

 https://wiki.ubuntu.com/Testing/EnableProposed

which sets the pin priority for proposed to 400, the page says to run a simulated apt upgrade to verify that no packages are scheduled for upgrade. However when we try that we see 11 upgrade-able packages.

We can get that number to 0 if we set the pin priority to something less than that of /var/lib/dpkg/status, i.e., to something less than 100. But is that correct?

If we comment out all the pin restrictions we see 44 proposed packages scheduled for upgrade. Is that because some of the proposed packages aren't controlled by /var/lib/dpkg/status?

Revision history for this message
Timo Aaltonen (tjaalton) wrote (last edit ):

just enable proposed, run 'apt install libgl1-mesa-dri libegl-mesa0' and you should get all relevant updates for mesa and nothing else

Revision history for this message
Sam (i41bktobiu5q-launchpadnet) wrote :

Following Timo's instructions, aptitude upgraded those two packages (along with three additional packages aptitude auto-selected) on one test system:

[UPGRADE] libegl-mesa0:amd64 22.2.5-0ubuntu0.1~22.04.2 -> 22.2.5-0ubuntu0.1~22.04.3
[UPGRADE] libgbm1:amd64 22.2.5-0ubuntu0.1~22.04.2 -> 22.2.5-0ubuntu0.1~22.04.3
[UPGRADE] libgl1-mesa-dri:amd64 22.2.5-0ubuntu0.1~22.04.2 -> 22.2.5-0ubuntu0.1~22.04.3
[UPGRADE] libglapi-mesa:amd64 22.2.5-0ubuntu0.1~22.04.2 -> 22.2.5-0ubuntu0.1~22.04.3
[UPGRADE] libglx-mesa0:amd64 22.2.5-0ubuntu0.1~22.04.2 -> 22.2.5-0ubuntu0.1~22.04.3

Rebooted and tested Chrome. No immediate issues, graphics work. Will keep testing.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mesa (Ubuntu Lunar):
status: New → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mesa - 23.0.3-0ubuntu2

---------------
mesa (23.0.3-0ubuntu2) mantic; urgency=medium

  * rules: Set VERSION so that it also includes the packaging
    revision. (LP: #2020604)

 -- Timo Aaltonen <email address hidden> Tue, 30 May 2023 09:53:55 +0300

Changed in mesa (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

marking verified according to #37, and also my testing shows it working

tags: added: verification-done verification-done-jammy
removed: verification-needed verification-needed-jammy
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

What's up with the lunar task that is still open? Lunar didn't have a mesa update yet, so it can't have regressed. I understand if we want to avoid future regressions in lunar too, of course, but the fix ("set VERSION so that it also includes the packaging version") should be bundled together with that future update of lunar, no?

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

marking invalid for lunar as it's not currently affected, and the next upload will bump to latest upstream version and also change the string to address this bug, but no need to verify that one for lunar

Changed in mesa (Ubuntu Lunar):
status: Confirmed → Invalid
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mesa - 22.2.5-0ubuntu0.1~22.04.3

---------------
mesa (22.2.5-0ubuntu0.1~22.04.3) jammy; urgency=medium

  * rules: Set VERSION so that it also includes the packaging
    revision. (LP: #2020604)

 -- Timo Aaltonen <email address hidden> Wed, 31 May 2023 11:21:54 +0300

Changed in mesa (Ubuntu Jammy):
status: Fix Committed → Fix Released
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Update Released

The verification of the Stable Release Update for mesa has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
oblong (bob-oblong) wrote :

For any Linux Mint 21.1 users... their systems may be behind in getting updates. But in the last few days I've had some users experience this problem with Google Chrome (Version 114.0.5735.198) and with Brave (Version 1.52.130). Thanks to posts here these fixes worked for me:

Chrome:
Delete ~/.config/google-chrome/Default/GPUCache

Brave:
Delete ~/.config/BraveSoftware/Brave-Browser/Default/GPUCache

(not to be confused with the older (?) ~/.config/brave... directory

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.