Chromium 81.0.4044.122 crashes on remote ssh connection

[Mike Bernson]

Chromium crash on a ssh x forwarding connection

It crashes on both 18.04 and 16.04 with the same message.
The X forwarding is working for other programs just fine.

It was working until last update.

Here is the message from the console on the crash

[22765:22781:0506/144206.193243:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye.
Trace/breakpoint trap (core dumped)

Steps to repeat:
ssh ltcd-prod
chromum-browser

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: chromium-browser 81.0.4044.122-0ubuntu0.18.04.1
ProcVersionSignature: Ubuntu 5.3.0-40.32~18.04.1-generic 5.3.18
Uname: Linux 5.3.0-40-generic x86_64
NonfreeKernelModules: btrfs xor zstd_compress raid6_pq ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c cpuid veth iptable_filter bpfilter bridge stp llc binfmt_misc intel_powerclamp coretemp kvm_intel kvm irqbypass zfs zunicode zavl icp ipmi_ssif gpio_ich crct10dif_pclmul crc32_pclmul ghash_clmulni_intel zcommon znvpair spl zlua aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate ast drm_vram_helper ttm drm_kms_helper lpc_ich drm joydev input_leds fb_sys_fops syscopyarea sysfillrect sysimgblt ipmi_si ipmi_devintf ipmi_msghandler mac_hid sch_fq_codel lp parport nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 hid_generic igb uas usbhid ahci i2c_algo_bit hid libahci usb_storage dca i2c_ismt
ApportVersion: 2.20.9-0ubuntu7.14
Architecture: amd64
DRM.card0-VGA-1:
 enabled: enabled
 dpms: On
 status: connected
 edid-base64:
 modes: 1024x768 800x600 800x600 640x480
Date: Wed May 6 14:37:46 2020
Desktop-Session:
 'None'
 'None'
 'None'
DetectedPlugins:

Env:
 'None'
 'None'
InstalledPlugins:

Load-Avg-1min: 0.55
Load-Processes-Running-Percent: 0.1%
Lsusb: Error: [Errno 2] No such file or directory: 'lsusb': 'lsusb'
MachineType: Supermicro A1SAi
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.3.0-40-generic root=UUID=c75e8c2a-b85d-444e-b278-16fd90c327e7 ro usb_storage.quirks=0bc2:331a:u,0bc2:ab31:u,0bc2:ab34:u
SourcePackage: chromium-browser
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/27/2015
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1.1a
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: A1SRi
dmi.board.vendor: Supermicro
dmi.board.version: 123456789
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 18
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.1a:bd08/27/2015:svnSupermicro:pnA1SAi:pvr123456789:rvnSupermicro:rnA1SRi:rvr123456789:cvnToBeFilledByO.E.M.:ct18:cvrToBeFilledByO.E.M.:
dmi.product.family: SMC X10
dmi.product.name: A1SAi
dmi.product.sku: 081315D9
dmi.product.version: 123456789
dmi.sys.vendor: Supermicro
modified.conffile..etc.default.chromium-browser: [deleted]

[Sebastien Bacher (seb128)]

Seems similar to https://support.google.com/chrome/thread/41722791?hl=en , does it work if you use --no-sandbox ?

[Mike Bernson (mike-mlb)]

That did work for both 18.04 and 16.04

Any idea what i lose by not having the sandbox ?

On 5/7/20 4:38 AM, Sebastien Bacher wrote:
> Seems similar to https://support.google.com/chrome/thread/41722791?hl=en
> , does it work if you use --no-sandbox ?
>

[Olivier Tilloy (osomon)]

Disabling the sandbox is not recommended, you're loosing process isolation.

Another suggested workaround in https://bugzilla.redhat.com/show_bug.cgi?id=1786306 is to run chromium with "--use-gl=swiftshader". Can you try that and let us know whether this works?

I'm marking this as a duplicate of bug #1857252 because they appear to be the same issue.

[Mike Bernson (mike-mlb)]

This is not the same problem.

The  --use-gl=swiftshader work for chrome before 81.0.4044.138. Without the --use-gl option it only had a blank (gray) screen but did not crash.
On 81.0.4044.138 it crashes (exits).

This is 2 different problems. With the end result being the same that chrome
does not work on x-forward connection.

On 5/14/20 11:45 AM, Olivier Tilloy wrote:
> *** This bug is a duplicate of bug 1857252 ***
> https://bugs.launchpad.net/bugs/1857252
>
> Disabling the sandbox is not recommended, you're loosing process
> isolation.
>
> Another suggested workaround in
> https://bugzilla.redhat.com/show_bug.cgi?id=1786306 is to run chromium
> with "--use-gl=swiftshader". Can you try that and let us know whether
> this works?
>
> I'm marking this as a duplicate of bug #1857252 because they appear to
> be the same issue.
>
> ** Bug watch added: Red Hat Bugzilla #1786306
> https://bugzilla.redhat.com/show_bug.cgi?id=1786306
>
> ** This bug has been marked a duplicate of bug 1857252
> chromium 79 remote display broken
>

[Olivier Tilloy (osomon)]

Ack. What about the suggestion in comment #12 in the upstream bug report (https://bugs.chromium.org/p/chromium/issues/detail?id=1026950) ?
Does this work around the crash?

[Mike Bernson (mike-mlb)]

Can no long test this bug as chromium has moved on to 81.0.4044.132 and now has a different set of problems.

Thing crash on on gpu problems.

Look at Bug 1877173.

On 5/15/20 7:58 AM, Olivier Tilloy wrote:
> *** This bug is a duplicate of bug 1857252 ***
> https://bugs.launchpad.net/bugs/1857252
>
> Ack. What about the suggestion in comment #12 in the upstream bug report (https://bugs.chromium.org/p/chromium/issues/detail?id=1026950) ?
> Does this work around the crash?
>

[Mike Bernson (mike-mlb)]

Sorry about last comment. (ignore last comment)

The workaround in bug 18752 fixes the blank screen. (This is also my bug report)
export QT_X11_NO_MITSHM=1
export _X11_NO_MITSHM=1
export _MITSHM=0

This work until 81.0.4044.122 which causes a crash (chromium exit) with
FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye

The --no-sandbox is a work around loosing process isolation. Which disabling the sandbox is not recommended,

The --use-gl=swiftshader was a work around for the blank screen not the crash and --use-gl option does nothing in 81.0.4044.138.

Summary so far:
 This is not same bug as 18752 but a new problem on a new version of chromium (Have not removed 18752 work around)
 There exists a work around --no-sandbox but is not recommended to use.

[Olivier Tilloy (osomon)]

Ack, thanks Mike. In light of this information, I have removed the duplicate status.

Is there an upstream bug report for the crash? If not, would you mind filing one at crbug.com ?

[Mike Bernson (mike-mlb)]

It look like
https://support.google.com/chrome/thread/41722791?hl=en

On 5/19/20 8:48 AM, Olivier Tilloy wrote:
> Ack, thanks Mike. In light of this information, I have removed the
> duplicate status.
>
> Is there an upstream bug report for the crash? If not, would you mind
> filing one at crbug.com ?
>
> ** This bug is no longer a duplicate of bug 1857252
> chromium 79 remote display broken
>

[Olivier Tilloy (osomon)]

Indeed, it appears to be the same problem. I think an actual bug report (as opposed to a support thread) would be useful if we want upstream developers to look into the issue.

[Mike Bernson (mike-mlb)]

I have reported the bug.

Here is the url.
https://bugs.chromium.org/p/chromium/issues/detail?id=1085136

On 5/20/20 8:24 AM, Olivier Tilloy wrote:
> Indeed, it appears to be the same problem. I think an actual bug report
> (as opposed to a support thread) would be useful if we want upstream
> developers to look into the issue.
>

[Olivier Tilloy (osomon)]

Thanks for the upstream report Mike. I see it has been marked as a duplicate of https://bugs.chromium.org/p/chromium/issues/detail?id=1035803, and comment #19 there suggests the following:

tldr; manually turn off shared memory by using the "--no-xshm" flag, setting the environment variable "QT_X11_NO_MITSHM=1" or "J2D_USE_MITSHM=0".

Does this address your crash?

[Mike Bernson (mike-mlb)]

it need the  no-sandbox to work.

On 6/11/20 10:57 AM, Olivier Tilloy wrote:
> Thanks for the upstream report Mike. I see it has been marked as a
> duplicate of
> https://bugs.chromium.org/p/chromium/issues/detail?id=1035803, and
> comment #19 there suggests the following:
>
> tldr; manually turn off shared memory by using the "--no-xshm" flag,
> setting the environment variable "QT_X11_NO_MITSHM=1" or
> "J2D_USE_MITSHM=0".
>
> Does this address your crash?
>

[Olivier Tilloy (osomon)]

https://bugs.chromium.org/p/chromium/issues/detail?id=1039560#c14 suggests that this should be fixed in the latest 83 stable update.

Would you mind testing that update from https://launchpad.net/~canonical-chromium-builds/+archive/ubuntu/stage and reporting whether the issue persists?

I'd recommend disabling that PPA after the test, the updates will eventually be available in the Ubuntu archive.

[Mike Bernson (mike-mlb)]

that fixes the --no-sandbox but still needs the
QT_X11_NO_MITSHM=1

also the --no-xshm works now.

This whole bug report shows my big problem with snaps.

In production I have a pin a version of chromium that works so that I can use
webdriver to access a number of site that I need to submit data to.

Once snap become in place I do not see any way to lock/pin a version of chromium that
works while the bug get fix.

How can problems like this be dealt with ?

On 6/12/20 10:52 AM, Olivier Tilloy wrote:
> https://bugs.chromium.org/p/chromium/issues/detail?id=1039560#c14
> suggests that this should be fixed in the latest 83 stable update.
>
> Would you mind testing that update from https://launchpad.net
> /~canonical-chromium-builds/+archive/ubuntu/stage and reporting whether
> the issue persists?
>
> I'd recommend disabling that PPA after the test, the updates will
> eventually be available in the Ubuntu archive.
>

[Olivier Tilloy (osomon)]

I'm glad that this update fixes the crash, thanks for the feedback.

I don't have a general solution to the problem you expose (pinning a specific revision of a snap), but in the description you mention 16.04 and 18.04, and both offer deb packages for chromium (the chromium deb was transitioned to a snap starting with 19.10), so at least in this specific case you can use apt pinning.

[Mike Bernson (mike-mlb)]

The pinning is holding me back for moving from current version to 20.04.

So far the only option I see is to use the beta you pointed me to or switch
to google-chrome which looks like there still create debs.

Not being able to pin things and not being able to choose when the snap upgrade
is a problem for product system. We use zfs for all the containers in production. We
take a snapshot before upgrade the deb packages. And if thing fail we the rollback
to the snapshot then clone container into testing area look at what failed. We can
then pin the deb we think caused and start testing again. Once the zfs clone work
we then apply the pin needed in production and the upgrade the production container.

For the time being we are only forced into snap for chromium. If we are force into snap for
other packages there a few lib that we have patches for to make sure they can not access
share memory for X11 (modify the testing for share memory to allways fail) which make
all of Gnome base code work 100% on the time instead of 60% without the patches.

Having to modified version of some lib will become a problem if more programs become
snap. We can config apt to allow us to handle this. We see now way to handle this under
snaps.

Also since the source code to build the snap is not  there is no way to audit the snaps.

Is there a good to post the problem we have with snap to see if something can be
done to expand the snap system to handle the problem we see.

Snap might work for the standard desktop system but a big problem for server in production.
We try to have a tight control over when updates to production happen and why.

Once snap has way for us to build them to make sure that they match the source code and allow
us to fix problem and submit the fixes upstream they might look better to us. Also snap should
have a way to configure ping/holding version and allow us to control when updates happen.

It looks like you are taking away control of system with snaps.

On 6/15/20 9:56 AM, Olivier Tilloy wrote:
> I'm glad that this update fixes the crash, thanks for the feedback.
>
> I don't have a general solution to the problem you expose (pinning a
> specific revision of a snap), but in the description you mention 16.04
> and 18.04, and both offer deb packages for chromium (the chromium deb
> was transitioned to a snap starting with 19.10), so at least in this
> specific case you can use apt pinning.
>

[Olivier Tilloy (osomon)]

Your concerns are valid. May I suggest you take them to a new thread on https://forum.snapcraft.io/ ? There will be many more eyes on it, and I'm sure you will get more elaborate and constructive answers there, than in this bug report.

Regarding the source code to build the snaps, in the case of chromium it is available there for everyone to audit: https://code.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/+ref/stable.