gmoccapy: fix SIGTERM/SIGINT hang while a modal dialog is up - #4501
Merged
Conversation
A modal dialog's gtk_dialog_run() loop is invisible to Gtk.main_quit(), so the GUI survived SIGTERM and the ui-smoke gmoccapy-quit test timed out. _terminate now destroys all other toplevels so run() returns and the unwind proceeds, with a forced exit as backstop. Also guard set_max_undo_levels() in hal_sourceview (dropped by newer GtkSourceView 4; the AttributeError popped the modal error dialog on CI), and harden the excepthook against a partially built app object.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4500.
Problem
The ui-smoke gmoccapy-quit test intermittently fails with
UI_SMOKE_QUIT_FAIL: GUI still alive 15s after SIGTERM, and c-morley confirmed the same lockup interactively: gmoccapy sometimes refuses to close and has to be killed.Root cause: GTK3's
gtk_dialog_run()spins a privateGMainLoopthatGtk.main_quit()cannot reach. When SIGTERM/SIGINT arrives while any modal dialog is up, the handler flags the outerGtk.main()for exit, but that loop cannot unwind until the dialog returns, and the dialog waits for an OK click that never comes on an unattended machine or a headless CI runner. The process then survives until SIGKILL.The trigger on the CI runner was an
AttributeErrorduring widget construction: newer GtkSourceView 4 releases droppedset_max_undo_levels(), and the exception popped gmoccapy's modal "Found an error!" dialog from the excepthook.Fix
In the SIGTERM/SIGINT handler: after
Gtk.main_quit(), destroy every toplevel except the main window. Destroying a dialog makes itsgtk_dialog_run()return, so the unwind proceeds to the outer loop and the process exits through the normal path (atexit handlers, HAL cleanup). A forcedos._exit()after 2s remains as a last resort. This covers not just the excepthook dialog but every modal dialog gmoccapy opens (entry, yes/no, system dialogs).Also:
hal_sourceview.py: guard theset_max_undo_levels()call withhasattr()so newer GtkSourceView 4 no longer raises during construction.NameError) when fetching the parent window, so an error raised before or during app construction is reported instead of being lost to a second exception inside the hook; destroy the dialog viatry/finally.Testing
Reproduced the exact CI failure locally (
GUI still alive 15s after SIGTERM) by injecting an exception into the running main loop under full CPU load. With the fix, the same scenario exits 1-3s after SIGTERM across repeated loaded runs, and the normal no-dialog quit path is unchanged (1s).