GNOME Bugzilla – Bug 334090
Crash while saving file during an in-progress transaction edit.
Last modified: 2018-06-29 20:59:15 UTC
I just ran into a crash from an assertion I added a week or so ago: ** ERROR **: file Account.c: line 277 (xaccFreeAccount): assertion failed: (acc->splits == NULL) Specifically, this happens because there is a transaction currently being edited in the register when I click 'quit' and then select 'save'. The Splits in the account don't get removed because their transaction's edit level is never dropping to zero. NOTE: Before I added this assertion, this was a silent data-corruption bug. It would have silent persisted parts of the in-progress transaction, even if it they did not balance. And since the imbalance checks were disabled during book shutdown (read saving) the imbalanced transaction would be saved without balancing. IOW, it would save a transaction like this: <gnc:transaction version="2.0.0"> <trn:id type="guid">8ce250fc0b815d91116f11efa2de0f23</trn:id> <trn:currency> <cmdty:space>ISO4217</cmdty:space> <cmdty:id>USD</cmdty:id> </trn:currency> <trn:date-posted> <ts:date>2005-11-10 00:00:00 -0500</ts:date> </trn:date-posted> <trn:date-entered> <ts:date>2005-12-22 22:11:07 -0500</ts:date> <ts:ns>40909000</ts:ns> </trn:date-entered> <trn:description>in progress edit</trn:description> <trn:splits> <trn:split> <split:id type="guid">476ea7f89b8612f66dd74e5db483f23b</split:id> <split:memo>in progress</split:memo> <split:reconciled-state>y</split:reconciled-state> <split:reconcile-date> <ts:date>2005-11-08 00:00:00 -0500</ts:date> </split:reconcile-date> <split:value>100/100</split:value> <split:quantity>100/100</split:quantity> <split:account type="guid">70d78e08aca2da44b026d95e8f2142d6</split:account> </trn:split> <trn:split> <split:id type="guid">900fcbca0016d8f62c66a2bb2dcf6d30</split:id> <split:memo>in progress2</split:memo> <split:reconciled-state>n</split:reconciled-state> <split:value>-83333/100</split:value> <split:quantity>-83333/100</split:quantity> <split:account type="guid">5340a7a55e6d9cba3f73d3c81ae604d6</split:account> </trn:split> </trn:splits> </gnc:transaction> (Note the imbalance.) What should happen: The register should ask 'record, discard, etc?' before saving the file. I've verified this was silent data-corruption in pre-r13434 and I've encountered the assertion failure in r13533.
Is this related to bug#155327 ?
Re: comment #1, no, not related.
Fixed in 13615.
So can the bug be closed?
*** Bug 334482 has been marked as a duplicate of this bug. ***
I'm still hitting this bug in a slightly different scenario. I don't hit it when clicking 'quit' or 'save' but when trying to open another file, which implicitly pops up the save dialog for the currently open book. I think it might be a better approach to just require that the in-progress edit be completed before allowing the register to lose focus. This would keep a "shorter account" (bad pun, I know) of open transactions. I don't really see much benefit in keeping multiple transactions open concurrently.
Not yet closed (in 1.9.5), is it?
No. Trying to open another file while editing a transaction is still broken. It lets you save the inconsistent state to a file and _then_ it asks you if you want to commit the transaction. Clicking 'Cancel' is the worst-case with the crash below. But that's not the real bug here. The real bug is that I should be asked to commit or discard the transaction _before_ saving the file. Program received signal SIGSEGV, Segmentation fault.
+ Trace 67902
Thread NaN (LWP 20637)
Fixed in r13871.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=334090. Please update any external references or bookmarks.