GNOME Bugzilla – Bug 343798
Assert at line 262 in split-register-load.c
Last modified: 2018-06-29 21:07:12 UTC
Steps to reproduce: 1. Open the attached file 2. Open a register for Assets:Broker Account:Corus 3. In the transaction on 11/1/1999 change the split for Assets:Broker Account:Corus to an amount of $323.36 4. Add a new split with zero shares and zero price and a value of $2909.99 credit to Assets:Broker Account:Corus to balance the transaction 5. Tab out of the transaction. 6. Click on the transaction dated 12/18/2003. Stack trace:
+ Trace 68631
Other information: The assert happens because pending_trans is not null. In fact it points to the 11/1/1999 transaction we just edited. This is with svn version 14298
Created attachment 66721 [details] Test file to use to reproduce the problem
It works correctly if you use enter to record the transaction instead of tabbing out of it.
:( Targeting.
I haven't been able to reproduce yet, but I'll keep trying. Initial comments: 1) My register starts in basic mode, so I click on the 'Split' toolbar button to expand. 2) When I enter 323.36, the balancing amount is 2,910.31, not 2,909.99. Was this a typo? 3) Since the share field starts empty, I only zero out the price field. 4) When I tab off the new split, I'm still in the same transaction. I see the duplicate of this transaction show up, since I have two splits for the Corus account. The cursor is in the second one. 4) When I tab out of that blank split, I get the Discard/Cancel/Record dialog. I choose Record. 5) There are 2 12/18 transactions. Which do you mean? Sell or Loss? (neither one crashes for me) 6) Tabbing out actually brings me to the first of the two 12/18 transactions, so clicking on it does nothing. Anyway, I've tried to trigger this 8-10 different ways, without success. I think I need more detailed instructions. It might also help to take a screen shot right before the click that triggers this.
Also, if you know the value of pending_trans, I guess it's because you've attached a debugger. If so, I'd also like to know the value of *info.
Some answers, keyed to the numbers in comment 4: 1. My register is in "Transaction Journal" mode. If it is in any other mode I don't see the bug. It doesn't matter whether "Enter moves to blank transaction" preference is selected or not. I forgot to mention this in the initial report, sorry about that. 2. Yes that's a typo. The correct amount is 2910.31. 3. Yes, zeroing the shares field is redundant. 4. When I tab off the new split the cursor leaves the transaction entirely (without opening a new split) and I never get the prompt to save or discard the changes. This is probably the heart of the problem. 5. It doesn't matter. Clicking on any other transaction causes the crash. 6. Tabbing out takes me to the blank transaction at the end, even if the "Enter moves to blank transaction" preference is not selected. I'll attach two screen shots. pic1.jpg is after step 4 in the original instructions and pic2.jpg is after step 5. There was exactly one tab between these two. The next click on any transaction will crash. The contents of *info at the time of the crash is (gdb) p *info $1 = { blank_split_guid = { data = '\0' <repeats 15 times>, __align_me = 0 }, pending_trans_guid = { data = "*,\345\245\002w\225Z\374\020\t\275\031/\223\244", __align_me = 707585445 }, cursor_hint_trans = 0x5903d60, cursor_hint_split = 0x5904f20, cursor_hint_trans_split = 0x5904f20, cursor_hint_cursor_class = CURSOR_CLASS_TRANS, hint_set_by_traverse = 0, traverse_to_new = 0, exact_traversal = 1, trans_expanded = 0, reg_loaded = 0, full_refresh = 1, default_account = { data = "\327\341\305;\267\265\215\255\t\037&u<\317\216\345", __align_me = -673069765 }, last_date_entered = 1149480000, blank_split_edited = 0, show_present_divider = 1, first_pass = 0, change_confirmed = 0, user_data = 0x59130a0, get_parent = 0x974b8 <gnc_ledger_display_parent>, template = 0, template_account = { data = '\0' <repeats 15 times>, __align_me = 0 }, debit_str = 0x5976c90 "Debit", credit_str = 0x5976cc0 "Credit", tdebit_str = 0x5976b70 "Tot Debit", tcredit_str = 0x5976e30 "Tot Credit" }
Created attachment 66756 [details] Screen shot before tabbing out of transaction
Created attachment 66757 [details] Screen shot after tabbing out of transaction There was exactly one tab event between this and pic1.jpg
Ok, thanks. Those screen shots helped. I can reproduce this now and I'm working on fixing it.
Update: This behavior was introduced in http://svn.gnucash.org/trac/changeset/13343 I'm currently thinking about ways to fix it.
I think this is fixed in r14345, but I'd really like some rigorous testing to assure me that r14345 doesn't break something else.
I'm feeling optimistic that r14345 didn't break anything else. I'm resolving as fixed.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=343798. Please update any external references or bookmarks.