Gnucash crashes when trying to scrub a security account. It seems to be realate to the fact that the remaining ammount from the previous lot is too small, and when splitting the value, the fact that one of the splits rounds to zero, makes Gnucash crash. Please find attached the log and thrown error: log: ... * 09:44:37 INFO <qof.engine> [qof_event_generate_internal] id=4 hi=0x557413168ad0 han=0x7fe2f7b7da70 data=(nil) * 09:44:37 INFO <qof.engine> [qof_event_generate_internal] id=3 hi=0x557412bb2f20 han=0x7fe2f87ee330 data=(nil) * 09:44:37 INFO <qof.engine> [qof_event_generate_internal] id=2 hi=0x557411bc4c90 han=0x7fe2f7ac90f0 data=(nil) * 09:44:37 INFO <qof.engine> [qof_event_generate_internal] id=1 hi=0x557411aa4260 han=0x7fe2f7b66810 data=(nil) * 09:44:37 INFO <gnc.lots> [xaccSplitAssignToLot] added split to empty lot, new lot baln=12084163/100000000 (Lot 3) * 09:44:37 INFO <gnc.lots> [xaccSplitAssign] have split 0x557413248050 amount=-12065812/100000000 * 09:44:37 INFO <gnc.lots> [xaccSplitAssignToLot] found open lot with baln=954/100000000 (Lot 2) * 09:44:37 INFO <gnc.lots> [xaccSplitAssignToLot] ++++++++++++++ splitting split=0x557413248050 into amt = -954/100000000 + -12064858/100000000 * 09:44:37 CRIT <gnc.lots> [xaccSplitAssignToLot()] Failed to split into two! * 09:44:37 INFO <gnc.lots> [xaccSplitAssignToLot] split value is = -1206/100 = 0/100 + -1206/100 error: gnc.engine:ERROR:/build/gnucash-gU7F_e/gnucash-3.4/libgnucash/engine/cap-gains.c:380:xaccSplitAssignToLot: assertion failed: (!gnc_numeric_zero_p (val_a))
Any chance you could give us reproducible steps?
He did, but in order to reproduce it you'll need to construct test data that matches the condition he described and is revealed in the tracefile fragment. One can even deduce from the tracefile that he's using a cryptocurrency (nothing else has 8 decimal digits) and that the split ratio produces a value that rounds to 0 in his real currency. The error shows that there's an assert on a run-time problem, which is wrong because it means that GnuCash can crash on users and lose their work since the last save. Since there's already plenty of error messaging about the problem the fix is to replace the assert with an unwind that skips processing that split.
