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.
Here’s the Terminal command that I ran: /Applications/Gnucash.app/Contents/MacOS/Gnucash --log gnc.ledger=debug And, here’s the line output to Terminal at crash: ** 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 --log gnc.ledger=debug The 5th line of the trace file doesn’t seem to be the right one. I’m not confident as to which line is the appropriate one to cite, but I’m sure that you’ll know. Attachment of the trace file and crash report to follow.
Realized that I needed to look at the 5th line of the crash report, so I found the reference sought after all: 5 libgncmod-ledger-core.dylib 0x000000010fa8cbd8 gnc_split_register_delete_current_split + 328 So, it cites gnc_split_register_delete_current_split. Attachments still to follow.
Created attachment 372894 [details] trace file
Created attachment 372895 [details] crash report Gnucash_2018-07-01-094547
I tried to copy your procedure from comment 18 with --log gnc.ledger=debug and compared the output to attachment 372894 [details]. The results don't match. Can you give key-bykey, click-by-click instructions?
I have also seen frequent crashes on macOS with 3.3 - good to know it’s not just me. Sometimes they even happen when gnucash is apparently idle. But yes, I have lost multiple transaction entries to crashes multiple times. I will update to 3.4 and see about generating some debugging info.
At this point it has become unusable to me, I have downgraded back to 2.6.19 and am eagerly awaiting a release that includes the upstream gtk library with the fix. https://gitlab.gnome.org/GNOME/gtk/issues/1312
That would be GnuCash 3.4, released last Sunday. It has gtk-3.24.2 with all of the Gdk-Quartz commits since then applied.
I will try that out! Minor point, the release notes could maybe mention a significant (at least for macOS users) update to a library dependency.
OK, though the release notes are already pretty long with just changes to GnuCash itself. There is, BTW, no reason to believe that this particular bug has anything to do with Gtk. The stack traces indicate hitting an assert in GnuCash code. However, I wasn't ever able to recreate it and the OP seems to have lost interest, so closing as incomplete. Jay, if you are still able to cause the crash with a current release and to provide the step-by-step procedure to recreate the crash by all means reopen the bug.
In early testing, 3.4 seems to have resolved the issue for me
