GNOME Bugzilla – Bug 618220
Adjustment in a split transaction cause gnucash to crash
Last modified: 2018-06-29 22:39:06 UTC
Created attachment 160680 [details] The information collected by MAC OS X 10.6.3 from the crash. Having used the Mortgage Druid to create a scheduled transaction for mortgage payment, the result of the druid is off by $0.01. After the transaction is entered, a manual adjustment is needed to correct that 0.01 error. That amount is added to the transaction decreasing the principle and the same amount is added to decrease in the intermediate account holding the payment funds. On making both adjustments, the gnucash program freezes for a number of seconds and then crashes. I've attached the information that MAC OS X puts together to communicate to Apple about the crash.
Are you editing transactions in the registers or transaction templates in the Scheduled Transaction Editor when the crash happens? Are you using the latest (2.2.9.4) dmg?
The About box simply says 2.2.9. It also says r17949M and dated 09/08/09. The scheduled transaction had been enter into the register by the automated process after asking. Noticing that there was a one cent error I was editing in the register.
Well, phooey. I can't replicate the crash, so I have to deduce what went wrong from the crash dump. The function flow is gnucash_button_event() -> gnucash_sheet_cursor_move() -> gnc_table_wrap_verify_cursor_position() -> gnc_table_verify_cursor_position() -> gnc_table_move_cursor_gui() -> gnc_split_register_move_cursor() -> gnc_ledger_display_refresh_internal() -> gnc_split_register_load() -> g_assertion_message_expr() That says that it asserted in gnc_split_register_load() after you clicked in a different transaction line. I found that in src/register/ledger-core/split-register-load.c, and reviewing the source code, there are two asserts: The first one checks if there's already a pending (that is, not saved) transaction open. The other one is a "not-reachable" that ensures that the function has succeeded in setting the current transaction as the pending transaction. I think that it's likely that the transaction you were editing hadn't been saved -- or at least that the pending_transaction pointer hadn't been cleared -- by the time that register_load was called on the new register. Why that might have happened I can't say. It doesn't happen when I try it. Have you tried again? Is it repeatable?
First I haven't tried again and at this point I'm likely to do so only the first week of every month as I adjust any rounding errors in the calculation of principle and interest. However, since i was setting it up to begin at the start of January and it is now May, I had it enter five months worth of transactions and each of them needed correction. So I probably crash the same way almost five times in a row. In that sense it was extremely repeatable. It only stopped repeating when I ran out of things to adjust and ran out of patience to put up with that. I believe that I may have moved from one field to another in the register to indicate I had finished editing the old field. Is there a save one should hit after changing one field of a row or one row? WIth experience mostly in Quicken, in split transactions in Quicken I would correct all the columns and rows in the table then click OK to save it to the memory copy. Periodically and when I was finished with a session, i would save the active file to backup in Quicken. Yes the why it happened does worry me a bit. When things crash I'm happier after a reason has been found, better when there is a workaround, and best when there is a fix. Without an explanation I worry about what might go wrong.
No need to repeat yourself. ;-) Moving to a different transaction with the mouse is a perfectly acceptable way to change transactions and shouldn't trigger the assert. Perhaps next time you could use the "return" key after you've adjusted the second split (use the tab and arrow keys to move around inside the transaction while you're editing or you may wind up with an imbalance split that you'll have to delete). Keep hitting return until you move out of the transaction completely. Let us know if it crashes then. Without being able to reproduce it, I can't really debug it to figure out what is the actual problem.
Nothing more heard after 4 months, so I'm closing the ticket. If the problem re-occurs with the latest release (currently 2.3.15.4) please open a new ticket.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=618220. Please update any external references or bookmarks.