GNOME Bugzilla – Bug 499215
crash in GnuCash Finance Management: Editing a split transact...
Last modified: 2018-06-29 21:54:56 UTC
What were you doing when the application crashed? Editing a split transaction where I'd swapped the two sides. So I was cutting and pasting the numbers in the split to generate the reverse transaction. Distribution: Debian lenny/sid Gnome Release: 2.18.3 2007-07-03 (Debian) BugBuddy Version: 2.18.1 System: Linux 2.6.23 #3 SMP Tue Oct 9 17:40:03 CDT 2007 x86_64 X Vendor: The X.Org Foundation X Vendor Release: 10300000 Selinux: No Accessibility: Disabled GTK+ Theme: Clearlooks Icon Theme: gnome Memory status: size: 338206720 vsize: 338206720 resident: 87277568 share: 18722816 rss: 87277568 rss_rlim: 18446744073709551615 CPU usage: start_time: 1195433426 rtime: 2053 utime: 2002 stime: 51 cutime:18 cstime: 1 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/gnucash' (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 0x2ace5dcfd980 (LWP 6598)] [New Thread 0x40800950 (LWP 6602)] (no debugging symbols found) 0x00002ace587a0c7f in waitpid () from /lib/libpthread.so.0
+ Trace 179382
Thread 1 (Thread 0x2ace5dcfd980 (LWP 6598))
----------- .xsession-errors (83868 sec old) --------------------- /etc/gdm/Xsession: Beginning session setup... <stdin>:7:2: error: invalid preprocessing directive #* XSET-done system defaults merged. user defaults merged. <stdin>:7:2: error: invalid preprocessing directive #* X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). Corrupt JPEG data: premature end of data segment X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). X connection to :0.0 broken (explicit kill or server shutdown). --------------------------------------------------
Sorry for this crash. A similar error was reported as bug 348469 and has been fixed in version 2.0.3. However, as you have seen this crash with version 2.2.1, obviously it wasn't fixed for all cases. You could help us fixing this bug by installing the package gnucash-debuginfo (or -dbgsym) from your distribution, then try to reproduce this bug and send us the (more verbose) stack trace. Thanks a lot!
*** Bug 493791 has been marked as a duplicate of this bug. ***
This bug is probably related to bug 501526, although the gdb output is a little different.
As of r17327, the variable "info" in gnc_split_register_load() in split-register-load.c does not get checked to see if it might be NULL before being dereferenced. That's a problem, but I don't think that's what is causing this gdb output. It looks more like the assert() at line 277 of the same function. I've never touched the register code, so I'm surely the wrong person to take this on, but I thought this information would be useful to whoever does.
I actually think there are a few ways to get a crash at this assert(). Although it isn't exactly what was reported above, here is a method that currently reproduces the failure in trunk: 1. Open a register in transaction journal mode. 2. Go to an existing transaction. 3. Transaction->Copy Transaction 4. Go to the bottom of the register to start a brand new transaction. 5. Type something in the description field. 6. Hit tab until the cursor reaches the first split line. 7. Go back to the description field. 8. Transaction->Paste Transaction Boom.
I can see why it crashes. The paste function deletes the "blank split" and doesn't replace it, leaving a register that, to the loading routine, paradoxically appears to have a pending transaction but no area to enter a brand new transaction. The paste function needs to be fixed to replace the blank split if it destroys it.
I've committed r17962, which fixes the method in comment 5. The original report doesn't give a precise method for reproducing the problem, however I can only assume that transaction pasting was involved, not simple copy/paste of text, and comment 5 produces the same backtrace. This is unlikely to be backported, so I'm marking this bug as "fixed" with a target release of 2.3.x.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=499215. Please update any external references or bookmarks.