From 52713704bcd927144c6fc25ddab247f412fee360 Mon Sep 17 00:00:00 2001 From: ispyisail Date: Thu, 17 Sep 2026 22:10:03 +1200 Subject: [PATCH] Offer the crash report after the recovery prompt, not instead of it (#901) QETApp::checkBackupFiles() only reached checkCrashDump() when there was nothing to recover: if (stale_files.isEmpty()) { checkCrashDump(); return; } A crash with a project open always leaves a stale KAutoSaveFile, so on the next launch the recovery prompt won every time and the dump sat on disk unoffered -- the report was unreachable in exactly the case it is most wanted. Reported by ChuckNr11 as a side note in #898: "the report appeared only once despite there being 10 or more crashes". It appears on the runs that happen to have nothing to recover. Discussion #644 step 5 asks that the two prompts never show at the same time, which this keeps: the recovery prompt is answered first, then the report. The recovery half moves into offerBackupFiles() so both paths fall through to the same place. Verified under Xvfb, from a real crash state (SIGABRT with a project open, leaving both a stale file and a 5.4 KB crash_dump.log): the recovery prompt appears, and dismissing it now brings up "Rapport de plantage" carrying the version, git SHA, OS, Qt version and the log ring. Before this change the report never appeared -- that half rests on the four lines above rather than on a captured before/after, since re-creating the crash state for a clean baseline run kept consuming it. Not addressed: the dump is a single fixed path opened O_TRUNC, so consecutive crashes still overwrite one another. ctest 8/8. Co-Authored-By: Claude Opus 5 --- sources/qetapp.cpp | 26 ++++++++++++++++++++------ sources/qetapp.h | 2 ++ 2 files changed, 22 insertions(+), 6 deletions(-) diff --git a/sources/qetapp.cpp b/sources/qetapp.cpp index d8e625d4d..4f334c676 100644 --- a/sources/qetapp.cpp +++ b/sources/qetapp.cpp @@ -2660,14 +2660,28 @@ void QETApp::checkBackupFiles() } } - if (stale_files.isEmpty()) { - // Only offer an unretrieved crash dump when there's no project - // to recover this run -- discussion #644 step 5 is explicit - // that the two prompts must never both show at once. - checkCrashDump(); - return; + if (!stale_files.isEmpty()) { + offerBackupFiles(stale_files); } + // Discussion #644 step 5 asks that the recovery prompt and the crash + // report never show at the same time -- not that the report be dropped + // whenever there is something to recover. Offering it here, once the + // recovery prompt has been answered, keeps the two sequential without + // losing the report after the most common crash there is: one with a + // project open, which always leaves a stale file behind, so the report + // was unreachable in exactly the case it is most wanted (issue #901). + checkCrashDump(); +} + +/** + @brief QETApp::offerBackupFiles + Ask whether to reopen the recovery files left by a previous run, and + open or discard them accordingly. + @param stale_files : the recovery files to offer +*/ +void QETApp::offerBackupFiles(const QList &stale_files) +{ QString text; if(stale_files.size() == 1) { text.append(tr("Le fichier de restauration suivant a été trouvé,
" diff --git a/sources/qetapp.h b/sources/qetapp.h index ee793ecb6..7d0e5e7ee 100644 --- a/sources/qetapp.h +++ b/sources/qetapp.h @@ -31,6 +31,7 @@ class QSplashScreen; class QMenu; class QAction; class QMainWindow; +class KAutoSaveFile; #define QETAPP_COMMON_TBT_PROTOCOL "commontbt" #define QETAPP_COMPANY_TBT_PROTOCOL "companytbt" @@ -290,6 +291,7 @@ class QETApp : public QObject void initSystemTray(); void buildSystemTrayMenu(); void checkBackupFiles(); + void offerBackupFiles(const QList &stale_files); void checkCrashDump(); void fetchWindowStats( const QList &,