[Aetf]

Overview

Fixes a heap-use-after-free that ASan catches in TestGuiFdoSecrets::testCollectionDeleteConcurrent on current develop (Qt 6.11, Debug/ASan build).

• Fixes Fdo Secret Service GUI tests crash on Qt6 #13307

Root cause

Closing a database tab may spin a nested event loop while the widget performs save-on-close (Database::save waits for its worker thread in AsyncTask::waitForFuture). If DatabaseTabWidget::closeDatabaseTab is re-entered for the same widget from within that nested loop — e.g. two concurrent FdoSecrets prompts deleting the same collection — QWidget::close() short-circuits on its internal is_closing flag and reports success immediately without delivering another close event.

This short-circuit is identical in Qt 5 and Qt 6 (QWidgetPrivate::close_helper in Qt 5.15 and QWidgetPrivate::handleClose in Qt 6 both start with if (data.is_closing) return true;), so none of the downstream guards — including DatabaseWidget::lock()'s m_attemptingLock — ever run for the re-entrant close. The bug is therefore long-standing rather than a Qt 6 regression; it was surfaced by scheduler timing under an ASan build with Qt 6.11.

The re-entrant call proceeds to removeTab() + deleteLater(), the DeferredDelete executes inside the still-running nested loop and destroys the widget under the outer invocation's feet; the outer call afterwards also repeats parts of the teardown (stale-index removeTab, deleteLater on the freed widget, duplicate databaseClosed emission).

Event trace of the failure (from an instrumented run; "first"/"second" are the two concurrent delete prompts):

1. first prompt: promptSync → closeDatabaseTab → close() → closeEvent → lock() → save → performSave → nested event loop in AsyncTask::waitForFuture
2. second prompt's timer fires inside that loop: closeDatabaseTab (tab still present) → close() returns true immediately (is_closing), no close event delivered → removeTab + deleteLater
3. ~DatabaseWidget runs via DeferredDelete inside the still-running nested loop
4. first prompt's save() resumes after performSave() → write to freed memory

Changes

• DatabaseTabWidget::closeDatabaseTab: track widgets with a close in progress; a re-entrant call returns false without side effects, and only the outermost invocation may remove the tab, schedule deletion, and emit databaseClosed (exactly once now). Also re-resolve the tab index after close() since nested event loops may shift tabs.

• FdoSecrets PromptBase::prompt: schedule promptSync only once; repeated Prompt() calls wait for the same Completed signal instead of running the prompt action multiple times.

• FdoSecrets DeleteCollectionPrompt: clear the collection reference on Collection::collectionAboutToDelete. The QPointer alone still sees a retired collection (already removed from D-Bus with m_backend reset) until its deleteLater is delivered, which would violate the invariant behind Q_ASSERT(m_backend) in Collection::doDelete. With the explicit clearing, "non-null m_collection implies usable backend" holds again and the assert stays intact.

• FdoSecrets LockCollectionsPrompt/UnlockPrompt (second commit): the same retirement window let these call doLock()/doUnlock() on a retired collection (assert in debug builds), and UnlockPrompt additionally hung forever when a collection went away mid-prompt — the retired collection never emits doneUnlockCollection (service connections are severed on retirement) and the count-based completion condition could never be satisfied, so Completed never fired. LockCollectionsPrompt now clears retired references (skipped like destroyed ones); UnlockPrompt tracks awaited collections in an explicit pending set (pre-registered before issuing any doUnlock, so synchronous completions of already-unlocked databases cannot prematurely trigger the item unlock step) and accounts retirement as a rejection, guaranteeing termination. Covered by the new testServiceUnlockConcurrentDelete regression test (unlock prompt waiting on user + concurrent Collection.Delete), verified to fail via signal-spy timeout without the fix.

• FdoSecrets Service unlock dialog bookkeeping (third commit): if the DatabaseWidget died while its unlock dialog was open, its m_unlockingDb entry stayed forever, keyed by a dangling pointer (identity comparison only, no UB) — permanently blocking doUnlockAnyDatabaseInDialog (unlock-before-search) and any future widget allocated at the same address. A cleanup connection on the widget's destroyed signal now removes the entry, in both the per-database and unlock-any flows. The regression test reopens the database after the concurrent delete and verifies the unlock dialog still appears; without the fix it times out in SearchItems waiting for a dialog that never shows.

• TestGuiFdoSecrets::testCollectionDeleteConcurrent: fix the second prompt proxy accidentally created from the first prompt's path — the test was exercising a double-Prompt() on one object rather than two concurrent prompts. Assert the fail-fast semantics: the losing concurrent prompt completes as dismissed while the winner performs the deletion.

Testing

On Arch (Qt 6.11.1, GCC 16, Debug + ASan), each test on an isolated private D-Bus session:

• testguifdosecrets: 36/36 pass (previously aborted with the UAF) — on a headless Wayland compositor (weston)
• testfdosecrets: 6/6 pass — same environment
• testgui: 47/50 — on Xvfb + openbox (X11), since this test relies on client self-activation which the Wayland protocol does not permit. The 2 failures are pre-existing focus-timing flakes under ASan slowness (editPassword->hasFocus(), QTestLib reports the 5s timeout as merely too short), plus 1 skip for the missing system tray

🤖 Generated with Claude Code