Crashing Konsole since upgrade to F43

Ask Fedora
, , ,
1

Hopefully this is the right place to ask about this.

Been having an annoying problem since upgrading from f42 to f43 both with the KDE spin: if I have a Konsole on another virtual desktop displaying a lot of output text, it segfaults and dies.

Having the same konsole foreground or background on the current virtual desktop isn’t a problem, having an idle konsole on another virtual desktop doesn’t seem to be a problem (unless of course the heavy output is hurrying things along). It also doesn’t seem that a process updating the terminal session frequently, like top with a subsecond sleep, will cause the crash.

It’s an issue whether I start a konsole then move myself to another desktop, or if I start a konsole and move it to another desktop while remaining set, if it tries to display a lot of scrolling output.

To test, I fired up Konsole in a gdb session, ran a small generic spammy script (just an echo in a loop) and moved it to another virtual desktop, a couple of seconds later I get:

0x00007ffff6675464 in QImage::isNull() const () from /lib64/libQt6Gui.so.6
(gdb) bt
#0  0x00007ffff6675464 in QImage::isNull() const () at /lib64/libQt6Gui.so.6
#1  0x00007ffff6898b22 in QPainter::drawImage(QRectF const&, QImage const&, QRectF const&, QFlags<Qt::ImageConversionFlag>) () at /lib64/libQt6Gui.so.6
#2  0x00007ffff1c9a6b4 in QtWaylandClient::QWaylandShmBackingStore::scroll(QRegion const&, int, int) ()
    at /lib64/libQt6WaylandClient.so.6
#3  0x00007ffff677ac3b in QBackingStore::scroll(QRegion const&, int, int) () at /lib64/libQt6Gui.so.6
#4  0x00007ffff72b266e in QWidgetRepaintManager::bltRect(QRect const&, int, int, QWidget*) ()
    at /lib64/libQt6Widgets.so.6
#5  0x00007ffff72b8f0c in QWidgetPrivate::scrollRect(QRect const&, int, int) () at /lib64/libQt6Widgets.so.6
#6  0x00007ffff7cf738b in Konsole::TerminalScrollBar::scrollImage(int, QRect const&, Konsole::Character*, int) () at /lib64/libkonsoleprivate.so.25.08.3
#7  0x00007ffff7ce1709 in Konsole::TerminalDisplay::updateImage() () at /lib64/libkonsoleprivate.so.25.08.3
#8  0x00007ffff5f6759a in void doActivate<false>(QObject*, int, void**) () at /lib64/libQt6Core.so.6
#9  0x00007ffff5f6759a in void doActivate<false>(QObject*, int, void**) () at /lib64/libQt6Core.so.6
#10 0x00007ffff7c2dc87 in Konsole::Emulation::showBulk() () at /lib64/libkonsoleprivate.so.25.08.3
#11 0x00007ffff5f6759a in void doActivate<false>(QObject*, int, void**) () at /lib64/libQt6Core.so.6
#12 0x00007ffff5f77d93 in QTimer::timeout(QTimer::QPrivateSignal) () at /lib64/libQt6Core.so.6
#13 0x00007ffff5f58f55 in QObject::event(QEvent*) () at /lib64/libQt6Core.so.6
#14 0x00007ffff723db9f in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
    at /lib64/libQt6Widgets.so.6
#15 0x00007ffff5efc4e8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt6Core.so.6
#16 0x00007ffff60d01f8 in QTimerInfoList::activateTimers() () at /lib64/libQt6Core.so.6
#17 0x00007ffff621e551 in idleTimerSourceDispatch(_GSource*, int (*)(void*), void*) ()
    at /lib64/libQt6Core.so.6
#18 0x00007ffff2d562a3 in g_main_context_dispatch_unlocked.lto_priv () at /lib64/libglib-2.0.so.0
#19 0x00007ffff2d5f1f8 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--
#20 0x00007ffff2d5f3a3 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#21 0x00007ffff621e80d in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /lib64/libQt6Core.so.6
#22 0x00007ffff5f09063 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
    at /lib64/libQt6Core.so.6
#23 0x00007ffff5f04819 in QCoreApplication::exec() () at /lib64/libQt6Core.so.6
#24 0x0000555555557921 in main ()

Crashing in:

$ rpm -qi qt6-qtbase-gui
Name        : qt6-qtbase-gui
Version     : 6.10.1
Release     : 2.fc43
Architecture: x86_64
Install Date: Sat 13 Dec 2025 03:26:04
Group       : Unspecified
Size        : 27518140
License     : LGPL-3.0-only OR GPL-3.0-only WITH Qt-GPL-exception-1.0
Signature   :
              RSA/SHA256, Mon 08 Dec 2025 18:44:58, Key ID 829b606631645531
Source RPM  : qt6-qtbase-6.10.1-2.fc43.src.rpm
Build Date  : Mon 08 Dec 2025 17:22:46
Build Host  : buildhw-x86-09.rdu3.fedoraproject.org
[..]

F43 is up to date as of early morning 2025-12-18, AuEST.

1 Like
2

I suspect you need to report to the kde folks over at https://discuss.kde.org where the expertise in Qt and konsole hang out.

I use konsole all the time and have not seen this issue under f43.

3

As with @barryascott, I cannot replicate.

I set up a konsole and a Ghostty session both spewing out nonsense in a while loop, moved them forwards and backwards between desktop 1 and 2 (and 3 and 4 tbh) and neither did anything other than spit out my wibble output from a busy loop.

I’m not a regular konsole user per se, but neither it nor ghostty cared if they were moved around from desktop to desktop whilst spewing output as fast as possible.

Do I need to actually run these terminals in a gdb session to try to trigger the crash as you see it, as I have nothing in journalctl to indicate a crash?

4

The issue may be GPU dependent. What is the output of `inxi -Gzxx?
I;m on a amdgpu.

5

Hi - I have the same problem since the last larger KDE update - with the initial konsole of vanilla KDE43 spin (simple rsync script) I’m able to backup a directory with 136GB (84.432 files) but since the last update the backup simply aborts konsole after some time. Script works fine in a bash, initial Fedora 43 KDE (however I have to admit I have not further investigated this problem - I rule out a hardware problem as its a beefy box and same backup works under another EL distribution same machine)

6

Does it still abort the script when it’s not running as a konsole command and emitting output to konsole? i.e. does it run cleanly when issued from cron for example, or the stdout/stderr is redirected to a file?

7 
Graphics:
  Device-1: Intel UHD Graphics 620 vendor: Lenovo ThinkPad T480 driver: i915
    v: kernel arch: Gen-9.5 ports: active: eDP-1 empty: DP-1, DP-2, HDMI-A-1,
    HDMI-A-2 bus-ID: 00:02.0 chip-ID: 8086:5917
  Display: unspecified server: X.Org v: 24.1.9 with: Xwayland v: 24.1.9
    compositor: kwin_wayland driver: X: loaded: modesetting unloaded: fbdev,vesa
    dri: iris gpu: i915 display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96
  Monitor-1: eDP-1 model: LG Display 0x0521 res: 1920x1080 hz: 60 dpi: 158
    diag: 355mm (14")
  API: EGL v: 1.5 platforms: device: 0 drv: iris device: 1 drv: swrast gbm:
    drv: iris surfaceless: drv: iris x11: drv: iris inactive: wayland
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 25.2.7 glx-v: 1.4
    direct-render: yes renderer: Mesa Intel UHD Graphics 620 (KBL GT2)
    device-ID: 8086:5917
  API: Vulkan v: 1.4.321 surfaces: N/A device: 0 type: integrated-gpu
    driver: mesa intel device-ID: 8086:5917 device: 1 type: cpu
    driver: mesa llvmpipe device-ID: 10005:0000
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: kscreen-console,kscreen-doctor wl: wayland-info x11: xdriinfo,
    xdpyinfo, xprop, xrandr

That’s how I noticed this to begin with, I’d start something and flick to another desktop, then depending on how much output it was trying to render, I’d get a “konsole aborted” KDE notification after a short time.

I haven’t yet had a problem when the konsole was on my current virtual desktop.

8

How do have scroll back buffer configured?

I wonder if you fill ram with old lines in the scroll back buffer.

9

Fixed size scrollback buffer, 65535 lines. The laptop has 32GB of RAM and disk-backed zswap, hitting that limit is usually quite noticeable. I can reproduce the issue with a fresh reboot and basically nothing else running.

Interestingly, I’ve just noticed something else, I described how to reproduce things incorrectly:

This bash snippet does not exhibit the issue:

$ while true; do echo 'a line of text that covers a about half a row, give or take'; done

Somehow, that works fine - left it running for about 60 seconds.

This, however, generates a crash 1-2 seconds after switching desktop away and is roughly the way I originally checked it (it was some unrelated Python that has a very short sleep to force a yield between each output line):

$ while true; do sleep 0.02; echo 'a line of text that covers a about half a row, give or take'; done

I grabbed the full konsole crash report this time (expiring link): Untitled - Pastebin Service

Sleeping for 0.01 works without crashing, same as letting it go flat-strap. 0.02, crashes after a couple of seconds. 0.05, after 10-15 seconds. 0.2 or 1, works fine for the length of time I let it run. Looks a lot like a weird race or timing interaction that I’ve managed to hit running my spammy Python inside SSH.

If nobody else has any ideas, I’ll throw this over to the KDE/Qt forum as suggested in the morning.

10

That replicates it here on my machine now too, using konsole, but only within bash.

If I use my usual shell (fish) it’s fine in konsole… move it to and fro without any issue.

1 Like
12

Same here. Switching the (virtual) desktop away always crashes konsole if something scrolls.
Not switching away, it seems stable.

13

Great work getting this in estigated!

Now that you have a reproducible way to crash konsole and a useful stack trace you should report to the kde konsole developers on the kde bug tracker.

14

Maybe this one:

1 Like
15

Which ends up with this bug report https://bugs.kde.org/show_bug.cgi?id=511945

2 Likes
16

The problem is you need a lot of output to konsole to trigger it and I only noticed it as I was testing something in konsole. Usually the scripts get started via a systemd unit file. Anyway somebody already filled a KDE bug report (511945) so it should get fixed upstream.

17

I’ve done a quick rebuild of the source RPM in question with the suggested patch, konsole no longer crashes. Looks like a proper fix is already in the works.

As a workaround if anyone else needs one in a hurry without recompiling: I spotted someone else noting the X11 backend for Konsole doesn’t have the problem: konsole --platform xcb. I’ve double checked that as well (before the patched rebuild) - no crashing.

1 Like
18

If you have access, can you reply on the bug report with your success?

1 Like