There is no activity indicator after Check and Repair All is chosen. I found it was possible to click on the menu headings, but the options were greyed out, but I was able to use File>Quit to shut Gnucash down. Shortly afterwards I got a crash report (Segmentation Fault). I was running this operation on a series of files after they had first been opened with 4.1 and then closed, and was probably moving faster than I normally would so as to get on with the next file. To reproduce the crash, open a file, run Check and Repair All, and within a few seconds use File>Quit. To work around the problem, leave Check and Repair to run to completion before quitting (if in doubt, use Activity Monitor to follow GnuCash's CPU usage - in my case when it dropped from 90% to 2% it was safe to quit.
Link to thread on Gnucash Users mailing list: https://lists.gnucash.org/pipermail/gnucash-user/2020-August/092459.html
I can pick up this bug if nobody's working on it. Jean
Jean, sure, go ahead. Michael, please attach the crash report.
Created attachment 373820 [details] Crash log caused by quitting while Check & Repair was running
I'm able to easily reproduce the issue. Note to devs: There's already a mechanism in GC to query each page before it's destroyed. The finish_pending() function returns a boolean to indicate whether the page is ready to quit. This is called via gnc_main_window_all_finish_pending() before exiting. It's easy to add a call to gnc_gui_refresh_suspended() to determine if an action is going on, and return FALSE if something's happening. Indeed this solves the issue. But I wonder why the default behavior is not to disallow quitting if gnc_gui_refresh_suspended() returns true as this indicates something's currently going on. In other words, why is it that gnc_quartz_should_quit() which calls gnc_main_window_all_finish_pending() does not also call gnc_gui_refresh_suspended() to determine whether an action is currently pending. Any idea what that's not the case?
Also, the repair mechanism does not seem to have a "cancel" or "abort" option. On a very large database, the repair takes forever, and the user has no way to interrupt it. Would it be worth adding that? Perhaps as part of the protection against quitting? For example: When the user attempts to quit, and the repair is ongoing, an alert window pops up "A repair action is in progress, do you want to abort it?". Abort and quit or cancel the quitting based on the user's response... Jean
Cancel or Abort are good if you are able to implement it safely. Visual feedback on the progress of the check & repair run would at least be as helpful.
I think it will take some SQL backend work to cancel safely: You'd need to checkpoint the DB and roll back to the checkpoint on cancel. For XML GnuCash should do a save at the beginning of the C&R and reload if the user cancels.
1) there's already visual feedback of the progress. It does not seem to work very well in debug mode, but it's there. 2) By canceling, I really meant aborting, but not reverting back to the original state: not an "undo". The repair works split by split, so it's very easy to put a flag and stop the process in between two splits. At least that way you don't get a crash (possibly leaving the database in an unreadable state) and the database would be left in a good state (not fully repaired but not damaged).
Possibly connected with this bug is a crash which happened yesterday, but which I haven't as yet been able to repeat. I started GnuCash which opened the most recently used file. Having checked that the "Save" option was greyed out, I used File->Open and selected the file I wanted to access. My suspicion is that although there were no Scheduled transactions set up in the first file, that GnuCash was busy with this file, but still allowed me to attempt the opening of a second file.
Michael, Since you're on a mac please always attach a the Console.app crash report when you report a crash. It makes it much easier to diagnose and to correlate with other bugs. Thanks.
Apologies. Have reproduced the crash this morning and will attach the crash log to a new bug report (as this wasn't triggered in the same way).
Jean Laroche's PR for the original bug is merged and will be in GnuCash 4.2. For the curious, Michael's new bug is bug 797918.
