GNOME Bugzilla – Bug 140400
Crash when deleting an account that is still in use by the business features
Last modified: 2018-06-29 20:42:57 UTC
Create a New Account in the chart of Business Accounts (e.g. Expenses:foo). Then: Business -> Employees -> New Expense Voucher Add an Invoice Entry, e.g.: 04/18/2004 blah Project Expenses:foo 1.00 1.00 1.00 Cash <Enter> Then Delete Account "Expenses:foo" from the chart of accounts. That's when it seg faults with a dialogue box that says: -begin- Application "/usr/bin/guile" (process [PID]) has crashed due to fatal error. (Segmentation fault) Please visit the GNOME Application Crash page for more information -end- In retrospect maybe it was stoopid to remove the Expenses:foo account from the chart of accounts while it was "in use" in the Expense Voucher but I had several entries in the voucher and while inputting other entries I noticed that there was an existing Expense account that I could use instead of the one I created. I thought that the entries that were tied to the Expenses:foo account would just "drop out" if I removed the Expenses:foo account from the chart of accounts and I could reenter them using the already existing Expense account instead.
Damn, I *KNEW* someone was going to hit this at some point. I was hoping it wasn't going to be for a while. In short: fixing this is HARD. I mean, REALLY hard. There's no hooks to do it, and then the question arrises of "what to do about it"? For now, all I can say is "don't do that." This is not going to be fixed in any 1.8 release. I'll see what I can do for 1.10/2.0 However, I will confirm the bug since I know it's there, and it is actually a much bigger problem than what you reported.
I get this same fault when trying to remove a split left over from a previous transaction. I enter a transaction and use a split and everything is fine. The next transaction I enter using the same Description brings up the split entry. When I try and remove the split and enter everything on one line, that is when I get the seg fault.
I'm a new user and have approx. one month of data entered into the GnuCash. Now suddenly, when starting up, GnuCash gives me a message that it cannot get a lock on data file. When selecting the option to opening it anyway, the above message pops up and the whole thing crashes. Unfortuntely I have now no way to acces my data. It's a pitty since GnuCash looked like a very powerfull application, however it needs to be stable as well. Any suggestions how to recover the data? Ales
Try reverting to a backup file from before you removed the account.
It works! Thanks! Can I do anything to avoid this in the future? best, ales
Don't delete accounts?
I don't remember deleting any accounts. I was actually trying to figure out how the scheduled transaction work. But like I say, I'm a beginner and may have done something stupid. Ales
I get this problem, too. When I try to import an OFX file (my credit card statement), the dialog pops up, and it prints two or three transactions before crashing. It gives the same error message as above. This is a big problem for me. If I can't import my credit card statements, my books will get progressively more outdated! I can downgrade to a previous version...how far back should I go? I'm using gnucash 1.8.10-12 on Debian unstable. guile is at version 1.6.7.
Uh, sorry dadrake, but OFX import has NOTHING to do with this bug. The fact that you get: Application "/usr/bin/guile" (process [PID]) has crashed due to fatal error. (Segmentation fault) Just means that gnucash crashed. There are lots of bugs that can cause that. This particular one is in no way related to OFX. You should either find one related to OFX or open a new bug report.
I just sent in a bug report using bug-buddy that in retrospect could be related to this bug. I see the crash when trying to add new accounts, but I did delete accounts before attemting to add new ones. Basically, I use the new file Druid to build a new business-type accounts file, delete the accounts my business will never need (no buildings, so no expenses and such, etc.) and add what is missing from the tree. From this bug I infer one can never delete accounts?
Scratch comment #10; I can reproduce my bug on a clean new file without accounts (and no deletes); sub-accounts cannot be added. I'll continue my commentary in the appropriate place -- the new bug (as soon as bugzilla mails me the number).
Derek said this bug is still relevant in current SVN. Made title more precise.
Is the problem here that there's a reference from the voucher to the account that the delete operation doesn't know about and is left dangling? Would reference counts help? With an SQL backend, we can start to define foreign key constraints which would prevent deletes, and the error could be propagated back up. A new "this object is going to be deleted - is that OK with you" callback which the business backend would use to check for references? How do we move forward with this?
Phil: Pretty much, yes. Reference counts could help, yes. But there's no way to delete an invoice so once you have a posted invoice you pretty much need to make the expense account un-deletable. So really the best way to do it would be to add a flag to an account that says "this account cannot be deleted". The "is this OK?" wont help. I dont know how to move forward with it, honestly.
The "is this OK" was meant to allow the business code to cancel a delete if it would delete an object being referred to. Is this also a problem in other places (delete a commodity that's the commodity for an account or the currency for a transaction)? Use gobject references to track these references? Add our own level of reference counting into GncObject and base all gc objects off of that?
I think it would be easier to mark the objects "undeletable". Doing the search is a potentially a large query. And yes, I suspect that commodities fall into the same issue. I don't know if a gobject reference is sufficient; Note that we probably want to also save that reference in the data file instead of computing it on the fly.
I'm not sure it would need to be computed on the fly. It would/could be a byproduct of the current engine and object pointers. For each transaction I load with a reference to a transaction currency, increment the commodity ref count. For each split I load with a reference to a containing account, increment the account ref #. For each expense voucher with a reference to an expense account, increment the account ref#. How is it currently handled that you can't delete an account with splits? Perhaps we should create GncObject with a list of referring objects. Then, if you want to delete the GncAccount based on GncObject, you can get the list of objects referring to the GncAccount and either cancel the operation or deal with them (e.g. move them to a new account).
if (account->splits) { pop_up_dialog; ... } Not all references are bad. Just because an object has references doesn't mean you can't delete it. For example, with an Account the account deletion code know how to handle moving splits on deletion. The problem here is that the core objects don't know about the business objects AT ALL. But that's something that shouldn't be corrected per se. Also note that not all data will be in core at the same time, so you can't assume that you can just use the GncObject; you might have an Invoice/Bill/etc from 5 years ago that doesn't get auto-loaded that refers to account X..
Well, eventually, we'll have a proper SQL app and use referential integrity checks to prevent these deletes.
*** Bug 608796 has been marked as a duplicate of this bug. ***
I have changed the title to widen the scope to all business features. The original poster triggered this bug by deleting an account that was used in an employee voucher. This bug will equally be triggered when deleting an account that is still in use in an invoice or a bill. Bug 608796 ran into this bug by deleting an account that was used in the tax tables.
r18893/18894 provide code so that the account deletion code can now get a list of business (or other) objects which have references to that account. This code can provide a dialog with this list so that the user can either cancel the delete or can modify the business objects to remove the references (or can shift the reference to a different account).
r18910 handles this for accounts. I don't know if there will be other issues with other core object types referred to by business objects.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=140400. Please update any external references or bookmarks.