Actually, here's what happened - long story short, I selected a destination account for the receiving end of a transaction, went to the register and deleted that account, then went back and saved the transaction, without remembering to change that account.

Thanks for taking the time to report this bug.
Unfortunately, that stack trace is missing some elements that will help a lot to solve the problem, so it will be hard for the developers to fix that crash. Can you get us a stack trace with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!

I think that instructions to reproduce the crash should be enough info to look into a bug like this. Whenever a bug like this is marked NEEDSINFO instead of getting investigated in earnest, I'm discouraged from submitting bugs in the future, because of what a time sink it is. However, I bothered to take a better trace anyway:


Distribution: Debian squeeze/sid
Gnome Release: 2.30.2 2010-07-17 (Debian)
BugBuddy Version: 2.30.0

System: Linux 2.6.32-5-amd64 #1 SMP Sat Jul 24 01:47:24 UTC 2010 x86_64
X Vendor: The X.Org Foundation
X Vendor Release: 10707000
Selinux: No
Accessibility: Disabled
GTK+ Theme: Clearlooks
Icon Theme: gnome
GTK+ Modules: gnomebreakpad, canberra-gtk-module

Memory status: size: 533086208 vsize: 533086208 resident: 64868352 share: 20905984 rss: 64868352 rss_rlim: 18446744073709551615
CPU usage: start_time: 1281847536 rtime: 1931 utime: 1807 stime: 124 cutime:22 cstime: 2 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/gnucash-bin'

[Thread debugging using libthread_db enabled]
[New Thread 0x7f1ede931710 (LWP 21976)]
0x00007f1eef844b4d in __libc_waitpid (pid=25876, 
    stat_loc=<value optimized out>, options=0)
    at ../sysdeps/unix/sysv/linux/waitpid.c:41
	in ../sysdeps/unix/sysv/linux/waitpid.c

+ Trace 223245

Current language:  auto
The current source language is "auto; currently asm".
Current language:  auto
The current source language is "auto; currently c".
A debugging session is active.

	Inferior 1 [process 21974] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]


---- Critical and fatal warnings logged during execution ----

** Gtk **: gtk_widget_is_ancestor: assertion `ancestor != NULL' failed 
** Gtk **: gtk_widget_is_ancestor: assertion `ancestor != NULL' failed 
** qof **: qof_instance_get_guid: assertion `QOF_IS_INSTANCE(inst)' failed 
** qof **: qof_instance_get_guid: assertion `QOF_IS_INSTANCE(inst)' failed 
** qof **: qof_instance_get_guid: assertion `QOF_IS_INSTANCE(inst)' failed 
** qof **: qof_instance_get_guid: assertion `QOF_IS_INSTANCE(inst)' failed 
** qof **: qof_instance_get_guid: assertion `QOF_IS_INSTANCE(inst)' failed 
** qof **: qof_instance_get_guid: assertion `QOF_IS_INSTANCE(inst)' failed 
** qof **: qof_instance_get_guid: assertion `QOF_IS_INSTANCE(inst)' failed 
** qof **: qof_instance_get_guid: assertion `QOF_IS_INSTANCE(inst)' failed 
** qof **: qof_instance_get_guid: assertion `QOF_IS_INSTANCE(inst)' failed 
** qof **: qof_instance_get_guid: assertion `QOF_IS_INSTANCE(inst)' failed 
** qof **: qof_instance_get_guid: assertion `QOF_IS_INSTANCE(inst)' failed 
** GLib-GObject **: g_object_set: assertion `G_IS_OBJECT (object)' failed 
** qof **: qof_instance_get_editlevel: assertion `QOF_IS_INSTANCE(ptr)' failed 


----------- .xsession-errors (672941 sec old) ---------------------
akregator(3180) Akregator::FeedIconManager::Private::loadIcon: Couldn't reach favicon service. Request favicon for  KUrl("http://lwn.net/")  failed 
kded(3200)/kdecore (services) KServiceFactory::findServiceByDesktopPath: "kded/favicons.desktop" not found
kded(3200)/kdecore (services) KServiceFactory::findServiceByDesktopPath: "kded/favicons.desktop" not found
akregator(3180) Akregator::FeedIconManager::Private::loadIcon: Couldn't reach favicon service. Request favicon for  KUrl("http://www.michaelgeist.ca/")  failed 
kded(3200)/kdecore (services) KServiceFactory::findServiceByDesktopPath: "kded/favicons.desktop" not found
kded(3200)/kdecore (services) KServiceFactory::findServiceByDesktopPath: "kded/favicons.desktop" not found
akregator(3180) Akregator::FeedIconManager::Private::loadIcon: Couldn't reach favicon service. Request favicon for  KUrl("http://www.metroidmetal.com/")  failed 
kded(3200)/kdecore (services) KServiceFactory::findServiceByDesktopPath: "kded/favicons.desktop" not found
kded(3200)/kdecore (services) KServiceFactory::findServiceByDesktopPath: "kded/favicons.desktop" not found
akregator(3180) Akregator::FeedIconManager::Private::loadIcon: Couldn't reach favicon service. Request favicon for  KUrl("http://en.community.dell.com/")  failed 
kded(3200)/kdecore (services) KServiceFactory::findServiceByDesktopPath: "kded/favicons.desktop" not found
kded(3200)/kdecore (services) KServiceFactory::findServiceByDesktopPath: "kded/favicons.desktop" not found
akregator(3180) Akregator::FeedIconManager::Private::loadIcon: Couldn't reach favicon service. Request favicon for  KUrl("http://www.pbs.org/")  failed 
...Too much output, ignoring rest...
--------------------------------------------------

Thanks for reporting this bug and sorry for the crash. Your instructions to reproduce in comment #1 are indeed sufficient. However, someone needs to check whether this still leads to a crash in the latest development version 2.3.15 - I think there have been some improvements when an account is being deleted, so that this doesn't lead to a crash. Testing with 2.3.15, anyone?

I'm afraid I can't even reproduce this crash on GnuCash 2.2.9 on Mandriva 2010.0.

When I follow the steps in comment #1, GnuCash simply asks me if I want to create the non-existing account. It doesn't crash.

Perhaps someone else can ?

Geert: before deleting the account, click or tab to the other line in the transaction. After deleting the account, the corresponding line in the pending transaction should be blank. At this point, if you hit enter, GnuCash will crash. Thanks for taking the time to look into this.

Ok, I managed to reproduce. There are some details missing in the steps to reproduce, so I'll repeat them in slightly more detail here:

1. Open an account register for some account, let's say AccountA
2. Go to the empty transaction line
3. Enter a transaction (description/other account/amount), but don't leave the transaction just yet! (Let's call the other account AccountB)
4. Enable split transactions
5. Click in the line representing the AccountA
6. Now go to the Accounts tab, and delete the AccountB
7. Return to the register for AccountA

=> You may notice here that the line representing AccountB no longer shows AccountB as other account. The amount remains though.

8. Finish the transaction by clicking outside of it, or hitting tab

=> Segmentation fault.

The problem is still there in version 2.3.15 by the way.

It took me a while, but I managed to hack around the crash.

The unstable branch starting from r21422 doesn't crash anymore for me, but it still produces a number of critical warnings in gnucash.trace.

I will see if I can get rid of those as well.

I have managed to improve the patch (in r21423). When running the steps to reproduce, only one critical message appear still in gnucash.trace.

The message is harmless in this case, but I don't see an easy way to avoid it.

What happens is this:
- After step 6, the account is deleted internally
- As part of this, the split is also marked for deletion via a call to xaccDeleteSplit.
- Since this split is part of an open transaction, it's not actually freed from memory yet, that happens only in step 8
- But deleting the account and marking the split as freed, trigger a series of callbacks to all interested components to update their states.
- One of the listening components is the register for Account A
- Part of this register's response is to rerun the query for its splits. Since the split hasn't really been deleted yet, it will be iterated by the query. 
- Somewhere in this process, the critical warning is generated. I presume because there is a test on the split's account, which is no longer valid at this point.

However once the transaction is committed in step 8, the split is truly freed from memory and won't appear in any future queries, hence no other critical qof messages pop up again.

Since the scenario that originally led to this crash is already a fairly uncommon one, I don't feel like spending more time to avoid this harmless critical warning, and intend to close the bug once it's backported to 2.4.

Created attachment 199148 [details]
Excerpt from gnucash.trace

For those interested in the last remaining qof critical warning, I have added a snippet from my gnucash.trace file run with debugging enabled.

This snippet gives some context to where the warning is generated. To keep it short, I have only taken the call to the relevant component update callback.
The whole is part of a call to gnc_resume_gui_refresh started from
src/gnome/gnc-plugin-page-account-tree.c:1240 or xaccAccountDestroy one line earlier.

Comment#9 said the bug is already fixed in trunk r21423. If back-porting isn't trivial, we can skip this and at least know that 2.5.x will have fixed it?

It turns out I had already backported this change to 2.4 (it's part of 2.4.9), but I forgot to update this bug's status.

Closing as fixed now.

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=626970. Please update any external references or bookmarks.