After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 796656 - GnuCash frequently crashes, usually involving unsaved transactions.
GnuCash frequently crashes, usually involving unsaved transactions.
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: MacOS
3.1
Other Mac OS
: Normal critical
: future
Assigned To: gnucash-mac-maint
gnucash-mac-maint
Depends on:
Blocks:
 
 
Reported: 2018-06-23 23:34 UTC by Jay
Modified: 2018-06-30 00:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
crash report 2018-06-23-144606 (66.58 KB, text/plain)
2018-06-23 23:34 UTC, Jay
Details
crash report 2018-06-23-133304 (66.54 KB, text/plain)
2018-06-23 23:35 UTC, Jay
Details
crash report 2018-06-23-131803 (69.04 KB, text/plain)
2018-06-23 23:36 UTC, Jay
Details
crash report 2018-06-16-235306 (69.07 KB, text/plain)
2018-06-23 23:40 UTC, Jay
Details
crash report 2018-06-16-091703 (70.36 KB, text/plain)
2018-06-23 23:41 UTC, Jay
Details
crash report 2018-06-14-235347 (66.70 KB, text/plain)
2018-06-23 23:41 UTC, Jay
Details
crash report 2018-06-13-220036 (70.49 KB, text/plain)
2018-06-23 23:42 UTC, Jay
Details
crash report 2018-06-10-231532 (69.05 KB, text/plain)
2018-06-23 23:42 UTC, Jay
Details
crash report 2018-06-10-205140 (69.02 KB, text/plain)
2018-06-23 23:43 UTC, Jay
Details
crash report 2018-06-10-162246 (68.83 KB, text/plain)
2018-06-23 23:43 UTC, Jay
Details
crash report 2018-06-10-144747 (68.65 KB, text/plain)
2018-06-23 23:44 UTC, Jay
Details
crash report 2018-06-05-115815 (71.71 KB, text/plain)
2018-06-23 23:44 UTC, Jay
Details
crash report 2018-06-03-210915 (66.82 KB, text/plain)
2018-06-23 23:45 UTC, Jay
Details
crash report 2018-06-03-201257 (66.52 KB, text/plain)
2018-06-23 23:45 UTC, Jay
Details
crash report 2018-06-03-131552 (68.12 KB, text/plain)
2018-06-23 23:46 UTC, Jay
Details
crash report 2018-05-28-194314 (66.68 KB, text/plain)
2018-06-23 23:46 UTC, Jay
Details
crash report 2018-06-23-222145 (68.58 KB, text/plain)
2018-06-24 05:26 UTC, Jay
Details
trace file (143.12 KB, text/plain)
2018-06-25 02:15 UTC, Jay
Details

Description Jay 2018-06-23 23:34:11 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”
Comment 1 Jay 2018-06-23 23:35:49 UTC
Created attachment 372784 [details]
crash report 2018-06-23-133304
Comment 2 Jay 2018-06-23 23:36:26 UTC
Created attachment 372785 [details]
crash report 2018-06-23-131803
Comment 3 Jay 2018-06-23 23:40:18 UTC
Created attachment 372786 [details]
crash report 2018-06-16-235306
Comment 4 Jay 2018-06-23 23:41:10 UTC
Created attachment 372787 [details]
crash report 2018-06-16-091703
Comment 5 Jay 2018-06-23 23:41:40 UTC
Created attachment 372788 [details]
crash report 2018-06-14-235347
Comment 6 Jay 2018-06-23 23:42:07 UTC
Created attachment 372789 [details]
crash report 2018-06-13-220036
Comment 7 Jay 2018-06-23 23:42:36 UTC
Created attachment 372790 [details]
crash report 2018-06-10-231532
Comment 8 Jay 2018-06-23 23:43:03 UTC
Created attachment 372791 [details]
crash report 2018-06-10-205140
Comment 9 Jay 2018-06-23 23:43:39 UTC
Created attachment 372792 [details]
crash report 2018-06-10-162246
Comment 10 Jay 2018-06-23 23:44:12 UTC
Created attachment 372793 [details]
crash report 2018-06-10-144747
Comment 11 Jay 2018-06-23 23:44:40 UTC
Created attachment 372794 [details]
crash report 2018-06-05-115815
Comment 12 Jay 2018-06-23 23:45:06 UTC
Created attachment 372795 [details]
crash report 2018-06-03-210915
Comment 13 Jay 2018-06-23 23:45:44 UTC
Created attachment 372796 [details]
crash report 2018-06-03-201257
Comment 14 Jay 2018-06-23 23:46:13 UTC
Created attachment 372797 [details]
crash report 2018-06-03-131552
Comment 15 Jay 2018-06-23 23:46:46 UTC
Created attachment 372798 [details]
crash report 2018-05-28-194314
Comment 16 Jay 2018-06-24 05:26:10 UTC
Created attachment 372799 [details]
crash report 2018-06-23-222145
Comment 17 John Ralls 2018-06-24 15:41:38 UTC
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.
Comment 18 Jay 2018-06-25 02:15:44 UTC
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.
Comment 19 John Ralls 2018-06-25 21:41:37 UTC
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.
Comment 20 Jay 2018-06-25 21:49:49 UTC
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”.
Comment 21 John Ralls 2018-06-26 00:20:42 UTC
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.
Comment 22 Jay 2018-06-26 00:31:23 UTC
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.
Comment 23 John Ralls 2018-06-26 18:54:59 UTC
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.
Comment 24 John Ralls 2018-06-30 00:12:13 UTC
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.