GNOME Bugzilla – Bug 796656
GnuCash frequently crashes, usually involving unsaved transactions.
Last modified: 2018-06-30 00:12:13 UTC
Created attachment 372783 [details] crash report 2018-06-23-144606 GnuCash frequently crashes. It seems that a crash is provoked most often in the following cases: Case 1: Attempting to delete a split from a new, unsaved transaction. Case 2: Attempting to save a transaction duplicated from a previous, unsaved transaction or attempting to delete a split from that transaction. Doing either of the above actions does not always result in a crash; it’s unpredictable yet frequent. In addition to the obvious interruption of a crash, the workaround is to neurotically save after entering a transaction or two. The more unsaved transactions, the more likely a crash and the greater the loss in time, having to reenter lost transactions. I launched GnuCash using Terminal to look at the “trace file” and was able to capture a crash error message provoked by Case 1 above; here’s that message: **gnc.register.ledger:ERROR:/Users/john/Development/Gnucash-Build/Gnucash-3-Mavericks/src/gnucash-3.1/gnucash/register/ledger-core/split-register.c:1072:gnc_split_register_delete_current_split: assertion failed: (!pending_trans)zsh: abort /Applications/Gnucash.app/Contents/MacOS/Gnucash Additionally, a number of crash reports were available in Console under User Reports. I’m not versed in examining them, however, so I‘ve simply attached the lot in reverse chronologically order. sincerely, Jay macOS 10.12.5 “Sierra”
Created attachment 372784 [details] crash report 2018-06-23-133304
Created attachment 372785 [details] crash report 2018-06-23-131803
Created attachment 372786 [details] crash report 2018-06-16-235306
Created attachment 372787 [details] crash report 2018-06-16-091703
Created attachment 372788 [details] crash report 2018-06-14-235347
Created attachment 372789 [details] crash report 2018-06-13-220036
Created attachment 372790 [details] crash report 2018-06-10-231532
Created attachment 372791 [details] crash report 2018-06-10-205140
Created attachment 372792 [details] crash report 2018-06-10-162246
Created attachment 372793 [details] crash report 2018-06-10-144747
Created attachment 372794 [details] crash report 2018-06-05-115815
Created attachment 372795 [details] crash report 2018-06-03-210915
Created attachment 372796 [details] crash report 2018-06-03-201257
Created attachment 372797 [details] crash report 2018-06-03-131552
Created attachment 372798 [details] crash report 2018-05-28-194314
Created attachment 372799 [details] crash report 2018-06-23-222145
The crash reports are mostly the same, so you can stop attaching them. A tracefile (https://wiki.gnucash.org/wiki/Tracefile) would be more useful at this point, particularly if you run GnuCash from Terminal and append --debug to the command.
Created attachment 372806 [details] trace file I created a new Gnucash file for experimentation and opened it from Terminal, appending --debug to the launch. I was able to rather quickly provoke a crash by: • Creating a new transaction with 3 splits; • Duplicating the unsaved transaction; • Deleting a split from the unsaved duplicate; • Duplicating, again, the unsaved duplicate; • Deleting a split from the unsaved second duplicate. At that point, Gnucash crashed. The trace file for this crash is attached.
What does "unsaved" mean in this context? I'm not able to replicate the problem: If "unsaved" means that the transaction isn't committed, IOW that it is still being edited and there is no "blank transaction" underneath it, GnuCash will neither duplicate nor copy it, so only the first step is even possible. If it means that the file hasn't been saved yet then I can duplicate and delete splits but no crash. There must be something more to it. Of the 16 crash reports, 8 are asserts from deleting the register window and 6 from deleting a transaction. The other two are segfaults, one from a cursor move causing a split destructor call on apparently a bad split and the other in a hash table, but I can't tell from the trace what hash table.
Perhaps uncommitted is more accurate; I don’t know. I mention saved because the Save button in the upper left is normally grayed out; however, upon making a change of any kind it becomes available. After creating a transaction but before clicking that save button, it can be duplicated any number of times. However many times it’s duplicated, though, all those transactions will be lost—I assumed because they were “unsaved”/uncommitted—in the event of a crash. The crashing is very irregular and unpredictable. I can can long stretches without a crash occurring, yet it can happen suddenly too without too much activity. It’s difficult to predictably replicate but does occur frequently. I think that I attempt to make the deletions mainly using the X button, whose meaning changes, but in the most common crash-inducing case has the meaning: “Delete the current split”.
Ah, the save button doesn't light up until the transaction is committed, so at least the first one is, and I suppose the second one must be as well. With the XML backend there's a difference; the SQL backend writes out to the database on every commit, but that would be really inefficient for the XML backend--it has to write out the whole file--so a commit means that the internal representation of the transaction is completed and (if it's an edit rather than a new transaction) the rollback instance is deleted.
Interesting! My files are XML, only because that was the sole option available for me at the time. On a previous version, XML and sqlite3 were the only backend options. After a few upgrades, ONLY XML was available for me. I had actually been meaning to inquire about this, as I continued to see references to other backends, yet I only had that option. , But it wasn’t urgent, so I didn’t. XML being the only option was true even through yesterday. This morning, I installed 3.2 yet had to revert due to Bug 796665. Now, having reinstalled 3.1, I see that multiple backend options are back—mysql, postgres, sqlite3, and xml.
Well, after several more tries I still can't get it to reproduce. Can you crash it again, this time with the command-line parameter "--log gnc.ledger=debug"? Attach the trace file and look at the crash report and say whether the 5th line of the stack trace is gnc_split_register_destroy or gnc_split_register_delete_current_split.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=796656. Please continue processing the bug there and please update any external references or bookmarks.