GNOME Bugzilla – Bug 102311
infinite loop in transaction processing
Last modified: 2018-06-29 20:24:13 UTC
When launching gnucash, I had the following behavior : 1. the window are opened 2. the reports are generated 3. a new window pops up "Schedule Transaction" 4. the cpu of the "guile" process run infinitely a 100% and the output is : ** CRITICAL **: file table-layout.c: line 265 (gnc_table_layout_set_cell): asser tion `col < cursor->num_cols' failed. ** CRITICAL **: file table-layout.c: line 265 (gnc_table_layout_set_cell): asser tion `col < cursor->num_cols' failed. ** CRITICAL **: file table-layout.c: line 265 (gnc_table_layout_set_cell): asser tion `col < cursor->num_cols' failed. Debug: gnc_formula_cell_set_value...(): internal string: Debug: gnc_formula_cell_set_value...(): internal string: Error: create_each_transaction_he...(): Null kvp_val for account Error: create_each_transaction_he...(): Null kvp_val for account Error: create_each_transaction_he...(): Unable to find common currency/commodity . The error lines are repeated quicky until the process is killed. In order to be able to get my accounts back, I removed by hand the scheduled transaction stuff at the end of the XML file.
This is reproducible with 1.8.[01]?
Just as a matter of interest, I had this one recently, with the current CVS. I still have no idea what caused it originally, but the offending SXs (there were a couple of them) had no account set for half of the split. Using the SX editor to fix this and setting an account for the offending SXs fixed the problem. This is a lot less work than deleting all SXs and entering them again. What is causing the looping is that create_each_transaction_helper() is running through, barfing on the bad SX, doing a rollback, exiting and then repeating the same SX, rather than skipping onto the next one, which would be a better recovery mechanism (if possible). Hope this helps. Nigel
Potential fix committed in gnucash-1-8 branch on 2003.05.18. Please re-verify on next release [or try the branch].
This still present in 1.8.4 (although the helpful diagnostic, telling which SX is at fault makes the manual fix a lot quicker).
The diagnostic says: "Error: create_each_transaction_he...(): Null kvp_val for account in SX "**********" -- fix manually; see http://bugzilla.gnome.org/show_bug.cgi?id=102311" However, one comes here and sees no helpful information on how to "manually" fix the problem. Could someone please post instructions on how to fix this? Thanks!
The fix is to correct the SX so that it has accounts for both sides of the transactions, as Nigel states. Then they run fine.
Another thing to do when this becomes a problem -- especially if scheduled transaction are set to run on startup -- is to: 1/ Start gnucash with '--nofile'. 2/ Change the preferences to not run since-last-run on startup. 3/ Re-start/re-open the offending file. Since Since-Last-Run no longer runs, the immediate problem goes away, at least. :/
If it can help : I created a scheduled transaction which move money from an account A to an another account B (how original !). After a while I decided that i didn't need A, then I deleted it. I didn't modify the scheduled transaction. When I started again the app went as described above. Hope it helps ...
*** Bug 109484 has been marked as a duplicate of this bug. ***
*** Bug 107360 has been marked as a duplicate of this bug. ***
We should do one of two things when an account that the template transaction depends on is removed: 1/ at the time the dependent account is removed, ask the user for SX handling direction ["removing this account will affect this SX... edit SX?"] 2/ at the time of since-last-run, ignore the SX but prompt the user to edit,delete it. This is an extension of the logging mentioned in previous comments, but involving actual updating and GUI stuff. Frankly, I like the former, better ... having that long-term subsystem messaging infrastructure in gnucash ["the user is removing this account ... anyone interested? SX? business? bueller? anyone?"] is a good/useful thing. At the moment, though, it's a future thing.
*** Bug 134589 has been marked as a duplicate of this bug. ***
This is mostly fixed in a 2004-03-08 commit on both the 1.8-branch and HEAD. In case gnucash cannot create the transaction, it will skip over the SX rather than looping indefinitely. I'll file another bug for the "should recognize dependent-account removal" issue.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=102311. Please update any external references or bookmarks.