Summary: | Spectacle crashed in ViewerWindow::~ViewerWindow | ||
---|---|---|---|
Product: | [Applications] Spectacle | Reporter: | postix <postix> |
Component: | General | Assignee: | Noah Davis <noahadvs> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | kde, kde, nate |
Priority: | HI | ||
Version First Reported In: | 6.4.4 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=414772 | ||
Latest Commit: | https://invent.kde.org/plasma/spectacle/-/commit/2ef3d91f38e31021587dd27f188a8a1d3c74e7ce | Version Fixed In: | 6.5.0 |
Sentry Crash Report: |
Description
postix
2025-08-28 12:53:05 UTC
Do you happen to recall what you clicked on? (In reply to David Edmundson from comment #1) > Do you happen to recall what you clicked on? I can only roughly sketch the workflow: 1) Took Rectangular screenshot 2) Likely edited it, I am not sure if I left the edit mode 3) Hit the Save At ... button and saved the screenshot 4) Not sure if I had deliberately closed Spectacle by clicking on the X in its titlebar If I find some time, I can try to reproduce it and pay more attention to the steps. Unfortunately, I can't reproduce this with the provided steps. I see there's also some output related to QML, so I wonder if it has to do with some kind of interaction between C++ and QML. > Unfortunately, I can't reproduce this with the provided steps.
Me neither. Looks like it's either extremely racy or some cosmic ray produced an unfortunate bit flip. Shall we close? I'm not sure, why David has marked it as "confirmed" first though.
Reported should be for things that aren't triaged.
The trace has everything we need.
>Object %p destroyed while one of its QML signal handlers is in progress or the application is running a nested event loop"
src/Gui/SaveAsAction.qml
10: onTriggered: contextWindow.saveAs()
invokes something from QML
That calls:
ExportManager::instance()->exportImage(ExportManager::Save | ExportManager::UserAction,
SpectacleCore::instance()->outputUrl());
exportImage goes into multiple paths with KJob::exec
They're just calling listDir and mkPath, so you'd need to be ninja fast to trigger that on a local filesystem.
If you manage to close the window whilst in that KJob::exec you unwind the stack and end up deleting the Button containing the QQuickToolButton which contains the saveAs action (which is what we see in the trace at frame 20 and 16)
A fast fix we do elsewhere would be running exportImage from a posted event (QTimer::singleShot(this, 0, ...) so that nested event loops aren't from QML space.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/spectacle/-/merge_requests/480 This had me confused for a while. I don't think the problem is with KIO, it's with the save dialog. Qt docs show the save dialog being used in a plain object variable with exec(), but this seems to be problematic because the crash occurs right where the dialog's exec() call is. I came up with a solution that uses open() and connections to finished(), but I have no way to verify that the issue is fixed. Git commit 18e5f3a8ccf091a4037d1b9de93ac3fe36d1a819 by Noah Davis. Committed on 13/10/2025 at 14:05. Pushed by ndavis into branch 'master'. Use QDialog::open and QDialog::finished instead of QDialog::exec to open QFileDialog M +54 -33 src/ExportManager.cpp https://invent.kde.org/plasma/spectacle/-/commit/18e5f3a8ccf091a4037d1b9de93ac3fe36d1a819 Git commit 2ef3d91f38e31021587dd27f188a8a1d3c74e7ce by Noah Davis. Committed on 13/10/2025 at 15:49. Pushed by ndavis into branch 'Plasma/6.5'. Use QDialog::open and QDialog::finished instead of QDialog::exec to open QFileDialog (cherry picked from commit 18e5f3a8ccf091a4037d1b9de93ac3fe36d1a819) Co-authored-by: Noah Davis <noahadvs@gmail.com> M +54 -33 src/ExportManager.cpp https://invent.kde.org/plasma/spectacle/-/commit/2ef3d91f38e31021587dd27f188a8a1d3c74e7ce |