Bug 430334 - Gwenview crashes when panning or zooming image (Wayland)
Summary: Gwenview crashes when panning or zooming image (Wayland)
Status: RESOLVED UPSTREAM
Alias: None
Product: gwenview
Classification: Unclassified
Component: general (show other bugs)
Version: 20.12.0
Platform: Fedora RPMs Linux
: NOR crash (vote)
Target Milestone: ---
Assignee: Gwenview Bugs
URL:
Keywords: drkonqi
Depends on:
Blocks:
 
Reported: 2020-12-13 12:34 UTC by david.p.warner
Modified: 2021-02-17 23:52 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description david.p.warner 2020-12-13 12:34:51 UTC
Application: gwenview (20.08.3)

Qt Version: 5.15.2
Frameworks Version: 5.76.0
Operating System: Linux 5.9.14-200.fc33.x86_64 x86_64
Windowing system: Wayland
Distribution: Fedora 33 (KDE Plasma)

-- Information about the crash:
- What I was doing when the application crashed:
Panning around or zooming into any image for a few seconds. If I pan or zoom just a little bit at a time, Gwenview won't crash, although the pan/zoom is very laggy. If the action is sustained, it reliably crashes.

- Custom settings of the application:
Happens regardless of whether 'Animations' are set to use OpenGL, Software or disabled ('None'). (Incidentally, the entire application's rendering is very buggy with the 'OpenGL' option, but this is probably a distinct issue.)

I use the open source AMD drivers. This same crash happens with 2 generations (Polaris and Navi) of GPUs.

Running Gwenview from the command line, I see these error messages when the crash occurs:

The Wayland connection broke. Did the Wayland compositor die?
KCrash: Application 'gwenview' crashing...

The crash can be reproduced every time.

-- Backtrace:
Application: Gwenview (gwenview), signal: Aborted

[KCrash Handler]
#4  0x00007fa86c79d9d5 in raise () from /lib64/libc.so.6
#5  0x00007fa86c7868a4 in abort () from /lib64/libc.so.6
#6  0x00007fa86cbc448f in QMessageLogger::fatal(char const*, ...) const () from /lib64/libQt5Core.so.5
#7  0x00007fa85ad9eeb3 in QtWaylandClient::QWaylandDisplay::checkError() const [clone .cold] () from /lib64/libQt5WaylandClient.so.5
#8  0x00007fa85adae0ea in QtWaylandClient::QWaylandDisplay::flushRequests() () from /lib64/libQt5WaylandClient.so.5
#9  0x00007fa86cdc43c0 in void doActivate<false>(QObject*, int, void**) () from /lib64/libQt5Core.so.5
#10 0x00007fa86cde16c8 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib64/libQt5Core.so.5
#11 0x00007fa86cd9357b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib64/libQt5Core.so.5
#12 0x00007fa86cd9b1b4 in QCoreApplication::exec() () from /lib64/libQt5Core.so.5
#13 0x000055d29f12210f in main ()
[Inferior 1 (process 3292) detached]

Possible duplicates by query: bug 430094, bug 430063, bug 429973, bug 429819, bug 429793.

Reported using DrKonqi
Comment 1 david.p.warner 2020-12-13 12:38:46 UTC
This may be a duplicate of https://bugs.kde.org/show_bug.cgi?id=430143, although that report doesn't indicate crashing. I can confirm that using the mouse wheel to zoom is responsive and does *not* trigger the crash. The only way I can trigger the crash-when-zooming is to click and drag the zoom slider at the bottom right back and forth for a while.
Comment 2 Nate Graham 2021-01-13 18:44:47 UTC
#6  QMessageLogger::fatal (this=this@entry=0x7fffd70c5ba0, msg=msg@entry=0x7ff994ac00b8 "The Wayland connection broke. Did the Wayland compositor die?") at global/qlogging.cpp:893

This means that the compositor crashed. Due to a Qt issue, when this happens, the app using it will crash too. KDE developers submitted a fix, but sadly it was not merged. See https://codereview.qt-project.org/c/qt/qtwayland/+/308984.

Until we get better handling of this in Qt, the best we can do is debug why the compositor crashed in the first place. So can you please get a backtrace of the crash in kwin_wayland and then file a new bug report with it on kwin | wayland-generic? Thanks!

You may be able to use the `coredumpctl` utility to retrieve the backtrace. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl
Comment 3 david.p.warner 2021-02-17 23:52:28 UTC
Thank you - sorry I didn't get around to doing this, but I can no longer reproduce the bug in Plasma 5.21, so it looks like the compositor bug has been resolved upstream.