Fatal: Chrome crashes whenever changing the monitor/dektop layout

English Applications
1

I recently converted my notebook from Leap 15.1 to Tumbleweed (by the usual zypper dup procedure).
Only since then my Google Chrome (the default google-chrome-unstable, currently at 85.0.4186.2) reliably (always) crashes by either attaching or detaching a USB-C connected (HiDPI) external monitor or by hanging a monitor setup parameter (e.g. resolution or orientation) with KDE systemsettings5.
This happens even with only a single browser window on the notebook’s internal display.
As in this case the browser does not have to re-render any window contents to adapt to a new screen resolution, I imagine that the problem may lay in the interaction between the desktop environment (Plasma/KDE) and the browser in case of a changed monitor setup.
Unfortunately, this also happens when leaving the notebook unattended, supposedly due to the monitor going to power saving mode.
Thus, I’m going through a browser restart procedure more than twice a day (with this is only feasible for me by temporarily disconnecting from the network due to me having usually 250+ tabs in 50+ windows open). Since I heavily rely on this browser for my daily work, any help would be appreciated:
Can someone please confirm this Tumbleweed issue?
Or narrow in by changing the desktop layout with a dual-monitor setup with the more common full HD resolution?
Or give some advice how further to analyze the situation?

Thanks in advance!

2

I narrowed this down to the following more simple (i.e. more broad and thus more severe) error conditions:

  • Whenever I change a monitor setup parameter (resolution, orientation, etc.) in systemsettings5 my google-chrome browser crashes (with the browser automatically reporting to Google)
  • This problem does not occur with the Firefox browser or other applications.
  • The problem also occurs in a single monitor setup❗ (i.e. just my Thinkpad’s internal display) and regardless how many browser windows are open.
  • Attaching/detaching an external monitor (or the monitor going into power saving mode) just triggers the same condition.
  • Changing the OpenGL version of the compositor (in systemsettings5) has no effect on this behavior (and also does not trigger the crash on its own).
3

I narrowed this down to the following more simple (i.e. more broad and thus more severe) error conditions:

  1. As already said, attaching/detaching an external monitor (or the monitor going into power saving mode) reliably (always) crashes the google-chrome browser (with the browser automatically reporting to Google).
  2. I found that the problem can easily be tested in systemsettings5 by just changing a monitor setup parameter (resolution, orientation, etc.) triggering the crash.
  3. It turns out that the problem also occurs in a single monitor setup (i.e. just my Thinkpad’s internal display):exclamation:and regardless of how many browser windows are open.
  4. Changing to a different OpenGL version of the compositor (in systemsettings5) has no effect on this behavior (and also does not trigger the crash on its own).
  5. This problem does not occur with the Firefox browser or other applications.
  6. As already said, the problem did not occur running up-to-date Leap 15.1.

Current software is Chrome 85.0 with Plasma 5.19 on Qt libs 5.15.

4

Please provide output here using code tags ( # above input window) input & output from:

inxi -CSGIxxx

Does it help to disable compositing in systemsettings5?

Is the 15.1 kernel still installed? If so, does booting it help?

5

Good evening Mr Mazda,

  1. In the systemsettings5 Compositor section disabled the “Compositor beim Start atkivieren” and did a reboot. The problem persists (same thing after activating the “XRender” option).

  2. The Leap 15.1 kernel is no longer installed (before “zypper dup” I replaced the package repositories to with the Tumbleweed repositories).

The output of the proposed inxi command is

 markov2:~ # inxi -CSGIxxx
System:    Host: markov2.fritz.box Kernel: 5.7.5-1-default x86_64 bits: 64 compiler: gcc v: 10.1.1 
           Console: tty 1 wm: kwin_x11 dm: SDDM Distro: openSUSE Tumbleweed 20200708 
CPU:       Topology: Quad Core model: Intel Core i7-8565U bits: 64 type: MT MCP arch: Kaby Lake rev: B 
           L1 cache: 256 KiB L2 cache: 8192 KiB L3 cache: 8192 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 31999 
           Speed: 806 MHz min/max: 400/4600 MHz Core speeds (MHz): 1: 806 2: 808 3: 808 4: 805 5: 806 
           6: 809 7: 805 8: 810 
Graphics:  Device-1: Intel UHD Graphics 620 vendor: Lenovo driver: i915 v: kernel bus ID: 00:02.0 
           chip ID: 8086:3ea0 
           Device-2: Chicony Integrated Camera type: USB driver: uvcvideo bus ID: 1-8:3 
           chip ID: 04f2:b67c serial: 6726 
           Display: server: X.Org 1.20.8 compositor: kwin_x11 driver: modesetting unloaded: fbdev,vesa 
           alternate: intel resolution: 1920x1080~60Hz s-dpi: 96 
           OpenGL: renderer: Mesa DRI Intel UHD Graphics 620 (WHL GT2) v: 4.6 Mesa 20.1.2 compat-v: 3.0 
           direct render: Yes 
Info:      Processes: 475 Uptime: 17:27:06  up 1 day 10:24,  21 users,  load average: 3.61, 3.11, 2.42 
           Memory: 15.32 GiB used: 10.43 GiB (68.1%) Init: systemd v: 245 runlevel: 5 
           target: graphical.target Compilers: gcc: 10.1.1 alt: 10/7 clang: 10.0.0 Shell: bash (su) 
           v: 5.0.17 running in: konsole inxi: 3.1.00

I.e. I’m running on a quite boring commodity hardware setup, i.e. standard Intel graphics and thus no problems due to non disclosed AMD or NVidia hardware “features” and Thinkpads are known to be quite Linux friendly.

Thanks for coming back on this.

6

This looks like a case for following the instructions for reporting Intel graphics bugs and/or reporting to the Chrome developers. I don’t know that any of the regulars here are running Whiskey Lake without NVidia or AMD graphics, and even if so, not also using Chrome.