GNOME Bugzilla – Bug 793768
Gnucash appears to "corrupt" data file: it opens the file correctly once but cannot parse it next time gnucash opens
Last modified: 2018-06-30 00:04:48 UTC
After upgrading from 2.6.15, Gnucash 2.7.4 appeared to start up as normal with all the usual reports, accounts and invoices open in tabs. After quitting though, it does not start up normally again, but complains of an error parsing the gnucash file. This seems to happen to every version of the data file I've tried (from backups.) It will open the file correctly once but never again; it doesn't help to "save as" a new file and open that, the same problem happens. The actual data file does not look corrupt and appears to be sane XML. The gnucash.trace says: * 17:45:06 CRIT <gnc.io> [dom_tree_generic_parse()] didn't find all of the expected tags in the input * 17:45:06 CRIT <gnc.io> [dom_tree_to_entry()] failed to parse entry tree * 17:45:08 WARN <gnc.backend> [GncXmlBackend::load()] Syntax error in Xml File /home/censored/accounts/censored-01-07-2008.20110801104535.xac.20180222202249.gnucash * 17:50:42 WARN <gnc.core-utils> Could not locate file AUTHORS * 17:50:42 WARN <gnc.core-utils> Could not locate file DOCUMENTERS * 17:50:42 WARN <gnc.core-utils> Could not locate file LICENSE * 17:53:11 CRIT <gnc.io> [dom_tree_handlers_all_gotten_p()] Not defined and it should be: entry:date * 17:53:11 CRIT <gnc.io> [dom_tree_generic_parse()] didn't find all of the expected tags in the input * 17:53:11 CRIT <gnc.io> [dom_tree_to_entry()] failed to parse entry tree * 17:53:13 WARN <gnc.backend> [GncXmlBackend::load()] Syntax error in Xml File /home/censored/accounts/censored-01-07-2008.20110801104535.xac.20180222202249.gnucash
As explained on IRC, this filename indicates that it's a very old file, renamed once in 2011 by GnuCash version 2.2.9 and again yesterday presumably by GnuCash 2.7.4. You indicated on IRC, however, that you'd successfully opened censored-01-07-2008.20110801104535.xac in GnuCash 2.7.4 and then saved it to a new name using File>Save As... Please start GnuCash and open the new file as follows, then *attach* the resulting tracefile to this report: gnucash --debug --extra /path/to/new_file.gnucash Making the obvious substitution, of course.
Created attachment 368852 [details] gzipped trace file of the (unsuccessful) attempt to open the result of "save as"
Repeating a request made on IRC#gnucash: OK, then there are two things to try. A diff between the old and new might be instructive. Depending on how many bills and invoices you have in the data file you might be able to examine the new file with less and find the entry that's missing an entry:date, then look at it in the old file and see what's recorded as the entry:date. Maybe there's a date-parsing problem.
A diff between the old and new shows the main difference to be <cmdty:space>ISO4217</cmdty:space> in the original file is replaced with <cmdty:space>CURRENCY</cmdty:space> in the new file. In addition, the GncEntry count-data value is less by one in the new file, i.e. <gnc:count-data cd:type="gnc:GncEntry">4626</gnc:count-data> in the original and <gnc:count-data cd:type="gnc:GncEntry">4625</gnc:count-data> in the new.
The change in the commodity namespace isn't germane, but the difference in the number of GncEntry counts supports my hypothesis that there's a problem with the entry date on one GncEntry. 4626 entries is a lot to search by hand. So load the original file and save-as to SQLite instead. Then you can use the sqlite3 command-line tool to query the entries table with select guid, date from entries where date_entered is NULL or date_entered = ""; Then you can find the guid in the original file and we can see what's weird about it.
I hope you haven't followed through with this, because I just found a problem in the SQL code that sets entry date and entry date_posted. That will be fixed in 2.7.7, which should get released on Sunday.
Meanwhile, over at bug 782144, the reporter has found that while he used to get the parsing error, with 2.7.8 and 3.0 GnuCash crashes instead. Could you try that with your file--the one saved with 2.6.x, not the damaged one.
I had the same problem with v3.0. It crashed with the following crash info: Process: Gnucash [7692] Path: /Applications/Gnucash 3.0.app/Contents/MacOS/Gnucash Identifier: org.gnucash.Gnucash Version: 3.0 (3.0) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: Gnucash [7692] User ID: 501 Date/Time: 2018-04-15 12:50:30.855 +0200 OS Version: Mac OS X 10.13.4 (17E199) Report Version: 12 Anonymous UUID: 8EAD55BE-C080-14DB-546B-A793ED83932C Time Awake Since Boot: 150000 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Application Specific Information: terminating with uncaught exception of type boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >: bad lexical cast: source type value could not be interpreted as target abort() called Suspecting a malformed date I did the following: I "grep"ed the xml datafile for "<ts:date> and then scrolled through the resulting file (over 9600 TX). I found a single transaction with a malformed date: 426139: <ts:date>13-04-26 11:52:28 +0053</ts:date> Changing this in GnuCash 2.6.21 using the date picker and saving the file again loaded it without problems in 3.0. Additionally, in v3.0 opening and saving the data file works, whereas in 2.7.x I had the same problem as the O.P. As it is working in 3.0 I have not further investigated 2.7.x
AJ, I've changed the date parser so that I think it won't crash like this anymore. Please try building from git to see if it fixes it for you.
Arnd, your report looks like bug 782144, for which we have committed a fix (to be released with gnucash 3.1). AJ, the exact steps you take to reproduce this crash are not completely clear to me. Is it like this: - open file a first time with gnucash 3.0 - quit without saving any changes - open file a second time with gnucash 3.0 => crash Or is it like this: - open file a first time with gnucash 3.0 - quit saving any changes - open file a second time with gnucash 3.0 => crash So the difference is in whether you tried to save any changes in between ?
(In reply to Geert Janssens from comment #10) > AJ, the exact steps you take to reproduce this crash are not completely > clear to me. Is it like this: > - open file a first time with gnucash 3.0 > - quit without saving any changes > - open file a second time with gnucash 3.0 > => crash This > So the difference is in whether you tried to save any changes in between ? No, no changes are required for it to corrupt the data file. John, thanks for the earlier message and apologies for not responding earlier - I have been flat out with other things but did set up a Linux Mint VM to try and get to the bottom of this; unfortunately my builds from git there crash on startup and I've not had a moment to figure out why. Will be in touch via IRC if I can soon.
(In reply to AJ MacLeod from comment #11) > (In reply to Geert Janssens from comment #10) > > AJ, the exact steps you take to reproduce this crash are not completely > > clear to me. Is it like this: > > - open file a first time with gnucash 3.0 > > - quit without saving any changes > > - open file a second time with gnucash 3.0 > > => crash > > This > > > So the difference is in whether you tried to save any changes in between ? > > No, no changes are required for it to corrupt the data file. > Your data file is xml and gnucash didn't even prompt to save changes on quitting (regardless of whether you made changes yourself or not) ? That's surprising but if that's really the case it's not your gnucash data file that gets corrupted but rather one of the metadata files. However that doesn't fit with the information you gave in the other comments. So now I'm puzzled :( > John, thanks for the earlier message and apologies for not responding > earlier - I have been flat out with other things but did set up a Linux Mint > VM to try and get to the bottom of this; unfortunately my builds from git > there crash on startup and I've not had a moment to figure out why. Will be > in touch via IRC if I can soon. It would be good if you could try to build gnucash 3.1. I has many fixes in the date handling in the business objects (that aspect of this bug report is very similar to bug 795377)
So it's been over two months since there was any significant activity here. We believe the salient issues are fixed but the reporter hasn't been able to test, so closing as fixed. AJ, if you find corruption problems with GnuCash 3.2 or later please open a new bug.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=793768. Please update any external references or bookmarks.