GNOME Bugzilla – Bug 125480
crashed while entering transaction
Last modified: 2018-06-29 20:38:18 UTC
Package: GnuCash Severity: normal Version: 1.8.7 Synopsis: crashed while entering transaction Bugzilla-Product: GnuCash Bugzilla-Component: Register Description: Description of Problem: crashed while entering transaction in general ledger Steps to reproduce the problem: 1. in general ledger, entered enough chars to bring forth a previous transaction 2. press tab Actual Results: crash Expected Results: continue entering transaction How often does this happen? not very often i have "gnucash-debuginfo": gnucash-1.8.7-1.9 gnucash-debuginfo-1.8.7-1.9 gnucash-backend-postgres-1.8.7-1.9 so what else should i do to make debugging symbols available for backtraces? Debugging Information: Backtrace was generated from '/usr/bin/guile' (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...[New Thread 1075058816 (LWP 5032)] (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...0xffffe002 in ?? ()
+ Trace 41174
Thread 1 (Thread 1075058816 (LWP 5032))
------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-10-25 11:04 ------- Reassigning to the default owner of the component, hampton@employees.org.
*** Bug 124979 has been marked as a duplicate of this bug. ***
i've discovered how to repeat this crash on demand. probably requires my data file tho.
Looks similar to the stack trace in bug 126471. g mottster: Can you paste those directions to duplicate the crash reliably here and attach the required file to this bug?
Created attachment 22551 [details] gnucash datafile for crash bug
hmm. now it won't reproduce. but hey, here's one that's similar. use attached datafile. launch. click 48. click Open. key: tab-tab-c-e-tab. click Jump. click CamphillCommTrustNI. click Split. select Actions->RemoveTransactionSplits. click RemoveTransactionSplits. Poof: Aplication "/usr/bin/guile" (process 23048) has crashed due to a fatal error. (Segmentation fault)
I can't reproduce using inctructions in comment 5 in either cvs head or in the cvs-1.8 branch. The two do work slightly differntly, however. version 1.8 won't allow the jump until the transaction is commited. version head does jump.
I can on r13300, though the instructions have changed a bit.
The general situation is having two transactions open for editing in seperate registers (A and B), where a split of the transaction in B references register A. Removing the splits from the txn in B forces gnc_split_register_load of A, which -- because there is a transaction pending in A -- uses the saved split-list [info->saved_slist] ... saved *before* the splits were removed from the txn in B, and as such now invalid. Specifically, the bug is in getting to this removed split, navigating to its parent transaction (here with obviously-invalid address 0x1000 :p) and calling xaccTransGetDate(...). Boom. All that being said, this is not the same as the originally reported bug and stack trace. But it's still a critical crasher on it's own, and reproducible as per Comment#5.
What I described in Comment#8 sounds very much like Bug#108347.
Believed fixed in r13343.
Hrmm. This is the incredible morphing bug. The instructions in comment#5 are not for the same bug as the original post and stacktrace. The original bug scenario doesn't involve mutliple open transactions, Instead, I think the original bug is from recalling a memorized multi-currency transaction. Notice that the data file contains several anomolies: A split with a zero exchange-rate: <trn:splits> <trn:split> <split:id type="guid">2907f4944fa672fb2587268e0a793409</split:id> <split:reconciled-state>n</split:reconciled-state> <split:value>2084/100</split:value> <split:quantity>0/100</split:quantity> <split:account type="guid">06a2f6bc8f2c4fc62d10e1e4267e4070</split:account> </trn:split> <trn:split> <split:id type="guid">523d1e40c3196685846014df7eafab41</split:id> <split:reconciled-state>n</split:reconciled-state> <split:value>-2084/100</split:value> <split:quantity>-2084/100</split:quantity> <split:account type="guid">d1e5b934b88bc5af62347b5522407fbd</split:account> </trn:split> </trn:splits> And several transactions with only one split, e.g.: <trn:splits> <trn:split> <split:id type="guid">28339d6eb5702a3e10cd87681cc24e94</split:id> <split:reconciled-state>n</split:reconciled-state> <split:value>298/100</split:value> <split:quantity>298/100</split:quantity> <split:account type="guid">06a2f6bc8f2c4fc62d10e1e4267e4070</split:account> </trn:split> </trn:splits> So, I think the _original_ bug is related to bug#130451, bug#126471, bug#125576 and probably hasn't been fixed yet. That said, I can't actually reproduce the crash described in the initial report. So, if bugzilla will let me, I'm going to leave this bug resolved but mark it as depending on bug#130451
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=125480. Please update any external references or bookmarks.