Wayland: crash when resizing secondary window and GNOME desktop has fractional scaling #103000

New Issue

Markus · 2022-12-07T23:48:39+01:00

Markus commented

2022-12-07 23:48:39 +01:00

System Information
Operating system: Ubuntu 22.04
Graphics card: Radeon 6800XT

Blender Version
Broken: 3.4.0, branch: blender-v3.4-release, commit date: 2022-12-06 18:46, hash: a95bf1ac01, type: release
Worked: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: b292cfe5a9, type: release

Short description of error
When performing a window resize operation by dragging the bottom right corner of a secondary Blender window (e.g. Window -> New Window) with the corner resize mouse cursor so that window width and height are changed at the same time, Blender has a high chance of crashing, i.e. repeating the resize operation multiple times will lead to a crash, sometimes already on the first resize.

Also the resize operation is really slow, taking around one second for the resized window to render after releasing the mouse button. When setting display scaling to 100%, I could no longer crash Blender but the resize operation was still very slow.

This is running under a vanilla Ubuntu GNOME session with GNOME 42.5. Display server is Wayland with 125% fractional scaling. Screen resolution is 5120x2160 pixels.

This was never an issue with Blender 3.3.1.

Exact steps for others to reproduce the error

Log in to a vanilla GNOME desktop session using Wayland under Ubuntu 22.04
Under GNOME settings -> Displays turn on "Fractional scaling" and set the scaling value to 125%
Launch Blender 3.4.0
Open a secondary window with Window -> New Window
Resize the window by dragging the bottom right corner resize window handle
Repeat 5. until Blender crashes

**System Information** Operating system: Ubuntu 22.04 Graphics card: Radeon 6800XT **Blender Version** Broken: 3.4.0, branch: blender-v3.4-release, commit date: 2022-12-06 18:46, hash: a95bf1ac01be, type: release Worked: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: b292cfe5a936, type: release **Short description of error** When performing a window resize operation by dragging the bottom right corner of a secondary Blender window (e.g. Window -> New Window) with the corner resize mouse cursor so that window width and height are changed at the same time, Blender has a high chance of crashing, i.e. repeating the resize operation multiple times will lead to a crash, sometimes already on the first resize. Also the resize operation is really slow, taking around one second for the resized window to render after releasing the mouse button. When setting display scaling to 100%, I could no longer crash Blender but the resize operation was still very slow. This is running under a vanilla Ubuntu GNOME session with GNOME 42.5. Display server is Wayland with 125% fractional scaling. Screen resolution is 5120x2160 pixels. This was never an issue with Blender 3.3.1. **Exact steps for others to reproduce the error** 1. Log in to a vanilla GNOME desktop session using Wayland under Ubuntu 22.04 2. Under GNOME settings -> Displays turn on "Fractional scaling" and set the scaling value to 125% 3. Launch Blender 3.4.0 4. Open a secondary window with Window -> New Window 5. Resize the window by dragging the bottom right corner resize window handle 6. Repeat 5. until Blender crashes

Markus commented

2022-12-07 23:48:39 +01:00

Added subscriber: @rasterizer

Campbell Barton commented

2022-12-08 06:19:12 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2022-12-08 06:19:12 +01:00

I'm unable to redo this in gnome-shell 43.1. although resizing does seem to be unreasonably slow.

Fractional scaling is an experimental feature in gnome, I needed to run:

gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

... then restart gnome-shell to access fractional scaling.

Otherwise Blender's Wayland support should work well as I used fractional-scaling during most of it's development with the "river" wl-roots based compositor (with each monitor set to a different scale at times).

I'm unable to redo this in gnome-shell 43.1. although resizing does seem to be unreasonably slow. Fractional scaling is an experimental feature in gnome, I needed to run: ``` gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']" ``` ... then restart gnome-shell to access fractional scaling. ---- Otherwise Blender's Wayland support should work well as I used fractional-scaling during most of it's development with the "river" wl-roots based compositor (with each monitor set to a different scale at times).

Campbell Barton changed title from ~~Blender crashes when resizing secondary window and GNOME desktop has fractional scaling applied~~ to [Wayland] crash when resizing secondary window and GNOME desktop has fractional scaling

2022-12-08 06:23:27 +01:00

Markus commented

2022-12-16 22:47:15 +01:00

As discovered in #102997, it is libdecor which is causing the performance issue. An open bug ticket exists for this under https://gitlab.freedesktop.org/libdecor/libdecor/-/issues/37 . On vanilla Ubuntu 22.04, when I install package libdecor-tests and then run libdecor-demo, I can reproduce these slow resizes. On a display with ~5kx2k resolution (with and without fractional scaling enabled), resizing this demo window to roughly more than half of my screen, the window resize repaints start taking around one second each, with some even taking 15 seconds to complete a single repaint.

Now for Blender, these long hangs appear to trigger the crashes for me most of the time in two ways:

While waiting for the repaint to render after triggering a resize by dragging the bottom right Blender window corner, I release the mouse button and then scroll the mouse wheel with the cursor within the Blender window area
While waiting for the repaint to render, I keep quickly dragging the window corner even though the Blender window has not updated yet

In both cases, Blender crashes and the following output appears on the shell where I started Blender:

GHOST/Wayland: Error sending request: Broken pipe
The Wayland connection broke. Did the Wayland compositor die?
Error: Not freed memory blocks: 95670, total unfreed memory 22.589180 MB
Freeing memory after the leak detector has run. This can happen when using static variables in C++ that are defined outside of functions. To fix this error, use the 'construct on first use' idiom.
Freeing memory after the leak detector has run. This can happen when using static variables in C++ that are defined outside of functions. To fix this error, use the 'construct on first use' idiom.
blender: ../external_epoxy/src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.
Freeing memory after the leak detector has run. This can happen when using static variables in C++ that are defined outside of functions. To fix this error, use the 'construct on first use' idiom.
Aborted (core dumped)

I assume comment https://gitlab.freedesktop.org/libdecor/libdecor/-/issues/37#note_1656985 ff. point towards the underlying issue causing this crash.

As discovered in #102997, it is libdecor which is causing the performance issue. An open bug ticket exists for this under https://gitlab.freedesktop.org/libdecor/libdecor/-/issues/37 . On vanilla Ubuntu 22.04, when I install package `libdecor-tests` and then run `libdecor-demo`, I can reproduce these slow resizes. On a display with ~5kx2k resolution (with and without fractional scaling enabled), resizing this demo window to roughly more than half of my screen, the window resize repaints start taking around one second each, with some even taking 15 seconds to complete a single repaint. Now for Blender, these long hangs appear to trigger the crashes for me most of the time in two ways: * While waiting for the repaint to render after triggering a resize by dragging the bottom right Blender window corner, I release the mouse button and then scroll the mouse wheel with the cursor within the Blender window area * While waiting for the repaint to render, I keep quickly dragging the window corner even though the Blender window has not updated yet In both cases, Blender crashes and the following output appears on the shell where I started Blender: ``` GHOST/Wayland: Error sending request: Broken pipe The Wayland connection broke. Did the Wayland compositor die? Error: Not freed memory blocks: 95670, total unfreed memory 22.589180 MB Freeing memory after the leak detector has run. This can happen when using static variables in C++ that are defined outside of functions. To fix this error, use the 'construct on first use' idiom. Freeing memory after the leak detector has run. This can happen when using static variables in C++ that are defined outside of functions. To fix this error, use the 'construct on first use' idiom. blender: ../external_epoxy/src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed. Freeing memory after the leak detector has run. This can happen when using static variables in C++ that are defined outside of functions. To fix this error, use the 'construct on first use' idiom. Aborted (core dumped) ``` I assume comment https://gitlab.freedesktop.org/libdecor/libdecor/-/issues/37#note_1656985 ff. point towards the underlying issue causing this crash.

Campbell Barton changed title from ~~[Wayland] crash when resizing secondary window and GNOME desktop has fractional scaling~~ to Wayland: crash when resizing secondary window and GNOME desktop has fractional scaling

2023-03-16 03:33:57 +01:00

Campbell Barton added the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Wayland: crash when resizing secondary window and GNOME desktop has fractional scaling #103000