GNOME Bugzilla – Bug 435642
Crash editing results of a find
Last modified: 2018-06-29 21:35:30 UTC
Steps to reproduce: 1. Open the (soon to be) attached file 2. Do a search for transactions posted before today (i.e. all transactions) 3. In the resulting find window select the Memo on the first split in first transaction (which reads "Opening balance"). Select the Memo on the split, not the description which is "Opening Balance". 4. Cut (control-X) 5. Arrow up. Stack trace:
+ Trace 132207
Other information: The first error is a PWARN "bad table location" at line 829 in gnc_table_move_cursor_internal. The stack trace is from this error. Then I get a lot of errors like * 17:05:34 CRIT <gnc.ledger> [gnc_split_register_get_trans_split()] bad row * 17:05:34 CRIT <gnc.register.gnome> gnucash_sheet_cursor_set_from_table: assertion `gnucash_sheet_cell_valid (sheet, v_loc)' failed This is followed by a crash with a long stack trace starting with 0 libSystem.B.dylib 0x90118798 localeconv_l + 24 1 libSystem.B.dylib 0x9000c738 __vfprintf$LDBL128 + 64 2 libSystem.B.dylib 0x9000c850 __vfprintf$LDBL128 + 344 3 libSystem.B.dylib 0x90103fcc vfprintf_l$LDBL128 + 124 4 libSystem.B.dylib 0x90106430 fprintf$LDBL128 + 112 5 libgnc-qof.1.dylib 0x0021f464 log4glib_handler + 244 (qoflog.c:115) 6 libglib-2.0.0.dylib 0x035efa80 g_logv + 1056 7 libglib-2.0.0.dylib 0x035efd50 g_log + 48 8 libgncmod-register-gnome.dylib 0x00651d50 gnucash_sheet_table_load + 688 (gnucash-sheet.c:2118) 9 libgncmod-register-gnome.dylib 0x00654348 gnc_table_refresh_gui + 184 (table-gnome.c:215) 10 libgncmod-ledger-core.dylib 0x005e2cc4 gnc_split_register_move_cursor + 1892 (split-register-control.c:471) 11 libgncmod-register-core.dylib 0x000a9450 gnc_table_move_cursor_internal + 192 (table-allgui.c:788) 12 libgncmod-register-core.dylib 0x000a9900 gnc_table_verify_cursor_position + 112 (table-allgui.c:929) 13 libgncmod-register-core.dylib 0x000a9a68 gnc_table_wrap_verify_cursor_position + 184 (table-allgui.c:994) 14 libgncmod-register-gnome.dylib 0x0064e528 gnucash_sheet_activate_cursor_cell + 104 (gnucash-sheet.c:238) 15 libgncmod-register-gnome.dylib 0x00654348 gnc_table_refresh_gui + 184 (table-gnome.c:215) 16 libgncmod-ledger-core.dylib 0x005e2cc4 gnc_split_register_move_cursor + 1892 (split-register-control.c:471) 17 libgncmod-register-core.dylib 0x000a9450 gnc_table_move_cursor_internal + 192 (table-allgui.c:788) 18 libgncmod-register-core.dylib 0x000a9900 gnc_table_verify_cursor_position + 112 (table-allgui.c:929) 19 libgncmod-register-core.dylib 0x000a9a68 gnc_table_wrap_verify_cursor_position + 184 (table-allgui.c:994) 20 libgncmod-register-gnome.dylib 0x0064e528 gnucash_sheet_activate_cursor_cell + 104 (gnucash-sheet.c:238) 21 libgncmod-register-gnome.dylib 0x00654348 gnc_table_refresh_gui + 184 (table-gnome.c:215)
Created attachment 87494 [details] File to reproduce the crash Use this test file to reproduce the crash with the instructions given above.
This was on Mac OSX, right? Anyone able to reproduce this on Linux?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
Reopening because the instructions are qualified enough. Still, the question is unanswered whether this occurs on Linux as well (so that the Linux-devs can reproduce this)?
Unable to reproduce using 2.2.1 on Windows.
Unable to reproduce here as well. Mike, is that still an issue with GnuCash 2.2.5? (I changed two tiny bits in the register code, you never know ;-))
I tried it in SVN r17143 and it still fails, although the failure is different. It first hits the "bad table location" warning in gnc_table_move_cursor_internal in table-allgui.c. Then it loops through the gnucash_sheet_cell_valid failure in gnucash_sheet_cursor_set_from_table in gnucash-sheet.c followed by the "bad row" error in gnc_split_register_get_trans_split in split-register-util.c. Eventually it dies with a segfault with 67456 levels on the stack (i.e. essentially a stack overflow). The top of the stack then is
+ Trace 197507
This is on MacOSX 10.4.11. I don't know why it would be different in this environment. I do know that I get these sorts of errors in normal use of Gnucash, but they usually aren't fatal.
Created attachment 126971 [details] [review] Patch that may fix this problem I finally got around to looking into this some more. I think the problem is a result of an interaction between gnc_split_register_redraw and gnc_split_register_find_split when called from gnc_split_register_move_cursor in split-register-control.c. As the comment says, "redrawing the register can muck everything up". In particular calling gnc_split_register_redraw may change the "transaction split" for some or all of the transactions if the register is a "ledger" style register such as the one for find results. This causes the subsequent call to gnc_split_register_find_split to find the wrong register row if the cursor class being found is CURSOR_CLASS_TRANS. Whether this causes a crash seems to depend on circumstances I haven't quite figured out, but I have one test file that crashes 100% of the time in r17804. This patch changes the way gnc_split_register_find_split works when asked to find the transaction split for a transaction. It assumes that any transaction can only have one such split and returns as soon as it finds a row containing it. If you think this is wrong, let me know and I'll try something else.
Trunk, r17853. Requesting back-port as this fixes a crash.
2.2-branch, r17864
Created attachment 127671 [details] [review] Corrected patch Unfortunately I realized in bed last night that the first patch I gave you for this bug isn't correct. It fails if you follow these steps: 1. create a transaction that has two or more splits in the same account 2. open a register on that account that is in either "Basic Ledger" or "Auto-Split Ledger" mode 3. change some transaction other than the one with multiple splits in this register 4. click on the second or succeeding occurrence of the transaction with multiple splits in this register This will put the cursor on the first occurrence of the transaction instead of the one you clicked on. If you are in auto-split mode it will also expand the one you really clicked on, but this is a separate bug. I've attached a second try at a patch to fix this. I tested this one with all the combinations I could think of and it seems to work. It's based on the results of the previous patch since that patch has been committed. Sorry I didn't think of this before you had committed the previous patch.
I'm reopening this bug since the patch that has been applied is wrong.
Applied as r17920 on trunk and r17923 on branches/2.2. Thanks a lot, Mike!
*** Bug 571663 has been marked as a duplicate of this bug. ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=435642. Please update any external references or bookmarks.