GNOME Bugzilla – Bug 573702
Unable to open saved file with scheduled transactions from 2.0.5 in 2.2.9 or newer
Last modified: 2018-06-29 22:19:01 UTC
When trying to open my file w/ all my tranastion info I get the following error message, "There was an error parsing the file" and the path to my file. I just d/led and installed GNUCash last night so there's not a lot lost, but that is a bit disconcerting if the file is corrupted only after once use.
Are you sure you tried to open the correct file? I suppose we have all opened a log file or similar ago. Do you see anything reasonable in the http://wiki.gnucash.org/wiki/Windows#Error_messages ? Can you open gnucash after appending " --nofile" to the last line of bin\gnucash.cmd? Will it reopen saved files from there?
GNUCash would start up, but I would get the error when I try to open my file. After appending the --nofile it starts over from the start. After running I select file -> open and select my file, which I called gnucash, and I get the error message. The file is stored in "d:\data\financial\GNUCash\gnucash". While playing last night I created a new file. While my old file wont open the new one will. Is there a way to recover my original file?
What about the error messages? I linked to an explanation in comment 1.
* WARN <qof.engine> [guid_init()] only got 2001 bytes. The identifiers might not be very random. * WARN <gnc.app-util> Could not spawn perl: Failed to execute child process (Invalid argument) * CRIT <gnc.io> [dom_tree_handlers_all_gotten_p()] Not defined and it should be: trn:date-posted * CRIT <gnc.io> [dom_tree_generic_parse()] didn't find all of the expected tags in the input
(In reply to comment #4) > * WARN <qof.engine> [guid_init()] only got 2001 bytes. > The identifiers might not be very random. > * WARN <gnc.app-util> Could not spawn perl: Failed to execute child process > (Invalid argument) > * CRIT <gnc.io> [dom_tree_handlers_all_gotten_p()] Not defined and it should > be: trn:date-posted > * CRIT <gnc.io> [dom_tree_generic_parse()] didn't find all of the expected > tags in the input > Also looked at the other wiki entries and nothing else seems to match what I'm seeing.
Hm, those messages appear in the mailing list archives, but no solution was presented. Have you tried to open a recent backup, i.e. a file ending on .xac?
Viola! I didn't realize that the xac files where the backups. I'm missing some of the data I put in, but it's better than starting over from scratch.
It would be very interesting to see the diff(erence) between the latest working and the first crashing backup file. If you do not see the XML contents when opening the files in your editor, try to unzip them first, e.g. with 7-zip. Do you think you can attach such a diff here?
Is there anything particular your looking for? I can use PSPad to do a diff on the files, but a lot of the differences will contain personal info that I would rather not post.
FYI, we've had a report of a similar issue with 2.2.9 in Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=493734), but haven't been able to get a file that trips up the parser yet.
Hello, I`m a winxp user and I installed the gnucash one month ago. Because I very offen I travel arround the country I try to use the gnucash over different PC. So, my file (that one saved with Save as...) can be opened on my first installed PC and my home PC. But can`t be opened on my laptop and another two XP machines and also on a PC with Win2000. All XP are SP3 and with all updates. All gnucash are 2.2.9. On some machines the message is in english: Can`t parse the directory ... On some machines the message is in romanan: Nu pot analiza URL C:\Documents and Settings\.... also in temp I have follows: gnucash.trace.UZ6Q0U * WARN <qof.engine> [guid_init()] only got 1914 bytes. The identifiers might not be very random. * WARN <gnc.app-util> Could not spawn perl: Nu s-a putut executa procesul copil (No such file or directory) gnucash.trace.RA82ZU * WARN <qof.engine> [guid_init()] only got 1875 bytes. The identifiers might not be very random. * WARN <gnc.app-util> Could not spawn perl: Nu s-a putut executa procesul copil (No such file or directory) * CRIT <Gdk> gdk_window_get_parent: assertion `GDK_IS_WINDOW (window)' failed * CRIT <GLib-GObject> g_object_ref: assertion `G_IS_OBJECT (object)' failed * CRIT <GLib-GObject> g_object_ref: assertion `G_IS_OBJECT (object)' failed Can you help me to solve this problem? Best regards, Mihail
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for (i.e. an example data file that demonstrates this behaviour.) Thanks!
Created attachment 157909 [details] Example file, triggers parse error problem The attached file triggers the parse error on read. It was created on Gnucash 2.0.3. Just a bare-bones tree with a single dummy scheduled transaction. To recreate the problem: Open the file in Gnucash 2.2.9 (it should succeed) Save (expect success) Re-open in Gnucash 2.2.9 - expect parse error "Check & Repair" doesn't seem to affect the results. Workaround: open in 2.2.9, delete all scheduled transactions, then save. Subsequent re-open in 2.2.9 succeeds, and can recreate the scheduled transactions. See also https://bugzilla.redhat.com/show_bug.cgi?id=493734#c16 ... which is where I found the workaround.
Reopening .... Still existing in 2.3.10, but gnucash.trace contains * 21:42:29 WARN <gnc.backend.file.sx> no template account with name [a0540cfe9c8d915fa93c18eab9593425] It seems, as if sx looks for names instead of guids. P.S. Attachment 157909 [details] is zipped.
Frank, you failed to reopen. I think this is not invalid. This is a real problem that we need to fix.
Derek, my intension was to confirm the bug and not the incompleteness. So it seems bugzillas logic differs from my. Next time I will select "unconfirmed".
No worries. It took me a bit to figure out how to reopen the bug. I was looking for a "REOPENED" state, but no, I had to make it "unconfirmed". Weird. But anyways, we should definitely look at this; it's a serious issue that 2.0 -> 2.2/2.3/2.4 SX upgrades fail!
I had no problems, when I performed the procedure from comment 13 with 2.2.7. So the fatal change happend between 2.2.7 and 2.2.9.
I tried loading this into the current svn trunk version and it seemed to have no problems. The "Since Last Run" dialog popped up to create the instance. When I turn on DEBUG logging in the file backend, I don't see any "no template account with name" messages.
(In reply to comment #18) > I had no problems, when I performed the procedure from comment 13 with 2.2.7. > So the fatal change happend between 2.2.7 and 2.2.9. This corresponds with what we've had reported in Fedora - the people who saw this said it started with 2.2.9.
So 2.0.3 -> 2.2.9 is broken, but 2.0.3 -> 2.3.x works? Phil, Frank seems to be able to reproduce this on 2.3.10 (see comment #14)
I'm not sure why he can reproduce it. The code which produces his warning is: static gboolean gnc_schedXaction_end_handler(...) { . . . sx = xaccSchedXactionMalloc(...); . . . if (sx->template_acct == NULL) { . . . acct = gnc_account_lookup_by_name(...); if (acct == NULL) { g_warning("no template account with name..."); return FALSE; } } } However xaccSchedXactionMalloc() calls xaccSchedXactionInit() which has: sx->template_acct = xaccMallocAccount(); so 'if (sx->template_acct == NULL)' should always fail.
Created attachment 158335 [details] problemFile-2.0-2.3.11.diff Hm, I should first select the file and then comment - OK, again: Also in 2.3.11 r19006 the bug exists, with the same gnucash.trace entry. So I compared the unzipped original file with the in 2.3.11 unchanged saved file (see attachement): Starting account and transaction set of the SX are lost in the new file. and the sx-id (GUID) is searched as account name. I fear, we should handle this issue as a blocker.
For what it's worth, I also got that gnucash.trace entry with 2.2.9 when re-opening the sample file: WARN <gnc.backend.file.sx> no template account with name [a0540cfe9c8d915fa93c18eab9593425] Also, general bug reporting question - I uploaded the sample file as generated by Gnucash 2.0.3 - should I have gunzipped before uploading?
I've upped the importance and changed the owner to Phil. We really should fix this before 2.4.0
Isn't the problem here that in the old version, the template SX including its template account is stored inside one top-level <gnc:template-transactions> XML element, whereas in the new file, this element has been removed and the template-account and <schedxaction> itself are top-level (in the gnc:book)? In that case the XML reading code must make sure to read the top-level <gnc:template-transactions> correctly.
I've tried a number of times and it doesn't happen on my system. Can someone else take this?
The described error happens always and reproducibly on my system (Ubuntu 10.04, gnucash SVN trunk). Did you notice that reproducing the error requires first opening the example file (without errors), then saving, then opening the newly saved file (now there is the error)? After these three (!) steps I can confirm the diff as posted by Frank Ellenberger - the account/transaction/split elements which were under the old <gnc:template-transactions> XML tag have plain disappeared in the newly saved file. Just a guess, but could it be a problem that src/backend/xml/gnc-schedxaction-xml-v2.c:810 contains an xaccAccountBeginEdit but there appears to be no matching xaccAccountCommitEdit?
From checking the history of xml/gnc-schedxaction-xml-v2.c only r15674 (referring to bug#412673) seems a little suspicious (might be deleting the currently used account), but even adding some extra checking to sx_set_template_account() doesn't change the error here.
Or could r17211 have caused this?
No, I didn't notice the extra save/load. I'll try again. Yes. OK. Now I see.
According to comment 18, the fatal change happened between 2.2.7 and 2.2.9. There's a change in io-gncxml-v2.c r17868. The checkin has: Changeset 17868 Timestamp: 01/31/09 14:50:08 (2 years ago) Author: cstim Message: Bug #569735: Don't create a new nested template root account when a file is opened Whenever an XML file is opened, Gnucash creates a new template root account and makes the old one a child of it. My main accounts file had them nested over 540 deep before I got annoyed enough to fix this. The problem is that sxtg_book_begin creates a root account when the book is opened. Then add_template_transaction_local tries to replace this new root account with the one read from the file. However the code that does this is rather badly broken and the result is that the one read from the file becomes a child of the one created in sxtg_book_begin. This patch avoids creating any more nested root accounts, but it doesn't get rid of the ones that are already there. This is slightly more tricky than just deleting them since, although most of them have no children (other than the next root account), some do. Accounts created for template transactions will be children of whatever root account happens to be at the top of the tree then. As the file is saved and reopened, this will get pushed down into the tree of accounts. In my case about 5 of the 540 or so root accounts had other children. Patch by Mike Alexander. BP
Thanks for looking this up. @Mike: Can you have a look into this again? The patch in question was contributed by you :-)
Hi, I resolved my problem. It was my mistake. On one pc I had GNUCash 2.2.9 and i had tried to open an xlm format from 2.3.4. This because I travel a lot and I portate my account on different PC. From my point of view this bug must be closed. Best regards! K
Created attachment 169607 [details] [review] Reverting r17868, which fixes this problem (but re-opens bug #569735) Should we apply this patch? The problem described here is fixed, but for sure Mike had some reason to file bug#569735 and fix that one by his original patch.
Let me take a look at it first. The original bug is a real bug too, even if perhaps not as major.
I just checked in r19559 which should fix this. The problem was that the old code (before bug#569735 was fixed) had a bug that the code which read old data files depended on. When the scheduled transaction reader is initialized it creates a template root account. Later when it finds a top level account in the input data it assumes that it is a template root account and tries to replace the one it created with the one it just read. There was a bug in that code that caused it to never work (it never replaced the dummy template root with the new one) which I fixed for bug#569735. Old data files don't have a template root account, but the scheduled transaction reader assumed any top level account was a template root account. When the bug was fixed it had the effect of trying to make every template account read from an old data file into the root account. This clearly didn't work. I changed it to understand the difference between a real root account and a non-root account that happened to be a top level account from an old data file. By the way, Christian, your comment in the patch you attached is correct (I think). It should be calling destroy not remove, but since the previous call to gnc_account_lookup_by_name always fails it doesn't really matter what it calls. That was the original bug. One thing I can't easily check is reading old data files with more than one scheduled transaction. If someone has such a file and can see if they can open it, save it, and open the newly saved copy I would appreciate it.
Comment on attachment 169607 [details] [review] Reverting r17868, which fixes this problem (but re-opens bug #569735) Thanks, Mike, for the quick response here! This is hopefully finally fixed. (BTW the comment in my patch wasn't from me, it merely was the original code that was removed in the old r17868.)
I can confirm from here: The provided test case is now working.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=573702. Please update any external references or bookmarks.