GNOME Bugzilla – Bug 143720
Replaying log file still creates broken transactions and can crash
Last modified: 2018-06-29 20:43:54 UTC
Make some changes to your data. Crash gnucash. Restart it. Try to replay the log file. Problems I saw: * In the dialog for opening the log file, if you enter a directory name in the text area and hit enter, then instead of switching to that directory as you'd expect, guile gets a segfault. * When clicking Save after replaying the log, I see this message lots of times: ** CRITICAL **: file sixtp-dom-generators.c: line 93 (commodity_ref_to_dom_tree): assertion `c' failed. * When exiting and restarting GnuCash after replaying the log and saving, I see this message lots of times: Warning: xaccTransFindOldCommonCurr...(): unable to find a common currency, and that is strange. Warning: xaccTransScrubCurrency: no common transaction currency found
*** Bug 150756 has been marked as a duplicate of this bug. ***
*** Bug 150187 has been marked as a duplicate of this bug. ***
I don't know if this is a variant of this bug, but I did manage to get gnucash into an infinite loop when trying to replay the log after a power outage. I doubt I could reproduce this now, though. Also, it's not clear how to make log replaying play nice in the face of scheduled transactions. Say that you last saved on 12/14. Then automated transactions apply on 12/15. If gnucash crashes on 12/16, and you restart with the 12/14 file, the automated transactions will try to reapply. Replaying the log now seems to want to recreate the auto transactions that already were added. This is in 1.8.9.
The cause of this bug is readily evident in src/import-export/log-replay/gnc-log-replay.c : void gnc_file_log_replay (void) { const char *selected_filename; ... DEBUG("Opening selected file"); log_file = fopen(selected_filename, "r"); if(ferror(log_file)!=0) { perror("File open failed"); } else If fopen returns NULL, say, because the file doesn't exist, then passing NULL to ferror will cause a SEGV, as ferror assumes a valid pointer to a FILE, and is usually implemented as a macro or an inline function. The fix would be : log_file = fopen(selected_filename, "r"); if((log_file == NULL) !! (ferror(log_file)!=0)) { perror("File open failed"); } else Regarding jlquinn's infinite loop, it must have had a different cause. I too managed to put gnucash into an infinite loop. I believe the mistake I made was attempting a replay of the current log file, which just kept growing as the replay continued indefinitely. If I can reproduce it under a controlled environment, I'll submit another bug.
Log replay related bugs: bug#143720 and bug#150514 and bug#165719 and bug#173056
*** Bug 157143 has been marked as a duplicate of this bug. ***
*** Bug 165719 has been marked as a duplicate of this bug. ***
Confirmed bug because of multiple reporting. Also see the duplicate bug#157143 for a larger backtrace. Raising severity because of crashing when selecting directory or non-existant file.
Created attachment 58902 [details] [review] Make scrub fix the missing currency in the transaction This doesn't fix the original problem (log replay may still create transactions without a trn:currency tag) but it will cause scrub (aka Check and Repair) to fix the problem. It will add a trn:currency tag to a transaction if it can infer a correct currency from the splits in the transaction.
Nice idea. I think this might also (indirectly) fix bug #106873 and bug #116353. Let me look at this a little harder.
Okay, I committed this patch in r13241. I haven't closed this bug because it's only a workaround, not a real fix. Perhaps we should call this new function more often?
Applied the change in comment #4 to SVN, r13282.
I added another change to r13283 which SHOULD fix this for good, at least in the cases where the new scrub function succeeds. Basically, every time we replay a new transaction I scrub it. So, I think this bug can now be considered "fixed". I've also updated the subject for posterity. Could you please test this revision and see if it fixes the problem? If it is still a problem, please reopen the bug. Thank you.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=143720. Please update any external references or bookmarks.