ispyisail
8623dd4c6f
openAndAddProject() shows BackupDialog as a stack object parented to the editor and exec()s it; every QET::QetMessageBox does the same. exec() runs a nested event loop, and closing the editor during it turns WA_DeleteOnClose into a deleteLater() that the nested loop processes: ~QWidget() deletes the editor's children, the stack-allocated dialog among them, and the process aborts. Reported on macOS, where File > Quit lives in the application menu and stays usable while the backup question is up. The close is now refused while any modal widget is active, and the dialog is raised so the refused quit is not silent. It is done in QETMainWindow::event() rather than in closeEvent(), because QETDiagramEditor::closeEvent() starts closing projects before it decides whether to accept. That covers the diagram and title-block editors; QETElementEditor is a plain QMainWindow, so its closeEvent() calls the same helper before canClose(), which itself opens a modal. QETApp::quitQET() needs nothing: closeEveryEditor() goes through each editor's close(), and quitQET() already only quits when every close succeeded. Rejected alternatives, both suggested on the issue: - Giving the dialog no parent stops the abort but not the deletion. One caller of openAndAddProject() is the editor's own constructor, which goes on to open the next file and call slot_updateActions() on this -- a loud abort would become a silent use-after-free. - Guarding only QETApp::closeEveryEditor(), which I first recommended on the issue, misses the reported route entirely: File > Quit is connected to QETDiagramEditor::close(), not to quitQET(). Verified on Linux, where there is nothing to click (the menu bar belongs to the blocked window, and Qt ignores window-manager close requests for it), by calling close() from gdb while the dialog's loop was running -- both QETApp::quitQET() and QWidget::close() on the editor. Unfixed, both abort with "free(): invalid size" in QObjectPrivate::deleteChildren() under ~QETDiagramEditor(), matching the report frame for frame; fixed, close() returns false, the editor and the dialog stay up, and after answering the dialog Ctrl+Q exits normally. The element-editor guard is the same helper but was not exercised separately. tests/modal-quit-regression/ turns that into a gate: it breaks on QDialog::exec(), interrupts inside the nested loop, calls quitQET() and checks the process survives. It matches no window titles (translated) and no window ids, runs on the offscreen platform, and needs only gdb with Python. Checked both ways: exit 1 with the backtrace above on a build without this change, exit 0 with it. ctest 8/8. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.9 KiB
Quit-during-modal regression test
Guards the abort reported in #904.
QETDiagramEditor::openAndAddProject() shows BackupDialog as a stack object
parented to the editor and exec()s it, and QET::QetMessageBox does the same
for every message box. exec() runs a nested event loop. Closing the editor
during that loop turns WA_DeleteOnClose into a deleteLater() that the nested
loop processes, so ~QWidget() deletes the stack-allocated dialog and the
process aborts. QETMainWindow::refuseCloseWhileModal() refuses such a close.
Running it
tests/modal-quit-regression/run.sh --binary build/qelectrotech
Needs gdb with Python. It runs on the offscreen platform, so no X server or
window manager is required. Takes about ten seconds.
Exit codes: 0 survived, 1 crashed, 2 the scenario did not happen.
How it works, and why this way
On Linux there is nothing to click: the menu bar belongs to the window the
dialog blocks, and Qt ignores window-manager close requests for a blocked
window. The reported route is macOS, where File > Quit lives in the application
menu and stays usable during a modal — and what it does is call close() while
the dialog's loop is running. The test does the same thing through gdb:
- break on
QDialog::exec(); - let the dialog's loop run, then interrupt it, so the main thread is inside
the nested loop — the only place the bug exists, because a
deleteLater()posted beforeexec()started is not processed by that loop; - call
QETApp::quitQET(), which closes every editor; - let it run: an unfixed build aborts within a second.
It matches no window titles and no window ids. Titles are translated, and
tests/ipc-regression once shipped a pass that could not fail because of that.
Checked both ways before being committed: it fails on a build without the fix
(signal 6, free(): invalid size) and passes with it.