After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 611853 - Entering a 2-digit year in the opening balance tab results in "Parsing Error"
Entering a 2-digit year in the opening balance tab results in "Parsing Error"
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: User Interface General
2.2.9
Other Windows
: Normal major
: ---
Assigned To: David Hampton
Chris Shoemaker
: 611020 626910 669061 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-03-05 00:33 UTC by Julie
Modified: 2018-06-29 22:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GNUCash file (9.27 KB, application/octet-stream)
2010-03-05 00:33 UTC, Julie
Details
GNUCash File New Dir (9.01 KB, application/octet-stream)
2010-03-06 00:38 UTC, Julie
Details
test.gnucash (3.48 KB, application/octet-stream)
2010-03-31 08:35 UTC, Jukka Zitting
Details
gnucash.trace file (589 bytes, text/plain)
2010-03-31 08:43 UTC, Jukka Zitting
Details
Screenshot of the Opening Balance tab (28.08 KB, image/png)
2010-03-31 10:08 UTC, Jukka Zitting
Details
Trace file covering the above steps 1-7 (468 bytes, text/plain)
2010-03-31 10:11 UTC, Jukka Zitting
Details

Description Julie 2010-03-05 00:33:19 UTC
Created attachment 155269 [details]
GNUCash file

I entered data into GnuCash for the first time today.  I saved all my data then closed the application.  When I tried to open it again using bin\gnucash.cmd I get this error: "There was an error parsing the file C:\Documents and Settings\jtripp\My Documents\Julie's\GNUCash\TrippFinances".  I cannot find any error logs to try to debug the issue myself so I have attached TrippFinances.  Hope you can help.  :-)
Comment 1 Geert Janssens 2010-03-05 10:40:22 UTC
There's a single quote in your path to your data file. I'm not GnuCash can handle that.

Can you try to create a gnucash file in another directory (like C:\temp) for testing, and see if that works ?
Comment 2 Julie 2010-03-05 16:13:40 UTC
I copied the folder to C:\GNUCash but still I get "There was an error parsing the file C:\GNUCash\TrippFinances."

Thank you so much for your help so far. :-)
Comment 3 Geert Janssens 2010-03-05 16:30:57 UTC
One more try: can you create a NEW file in C:\GNUCash ?

It is possible GnuCash couldn't write properly to the TrippFinances file while it was in the path with the single quote in it. In that case the TrippFinances file would be invalid for GnuCash.

Oh, and by the way, which version of Windows are you using ?
Comment 4 Julie 2010-03-05 17:27:11 UTC
I'm using Windows XP Pro SP3.

Later today I will try to recreate my file from scratch in C:\GNUCash.  Hopefully this will fix the issue.
Comment 5 Julie 2010-03-06 00:38:34 UTC
Created attachment 155394 [details]
GNUCash File New Dir

I tried to duplicate my last GNUCash account from scratch at C:\GNUCash, but I'm still getting "There was an error parsing the file C:\GNUCash\TrippFinances2." after I try to re-open.

If I save without entering data then close and re-open it's fine, but after I enter data I get this parsing error.

I have attached my new file.  :-\
Comment 6 Geert Janssens 2010-03-07 11:05:18 UTC
I can confirm this even on linux with your data file.

For the record, after the parsing error this is printed in gnucash.trace:

* 11:52:15  CRIT <gnc.io> [dom_tree_handlers_all_gotten_p()] Not defined and it should be: trn:date-posted
* 11:52:15  CRIT <gnc.io> [dom_tree_generic_parse()] didn't find all of the expected tags in the input

And this transaction is printed on the console:
<gnc:transaction version="2.0.0">
  <trn:id type="guid">ab599f5e61e18e725168d08cfb034f65</trn:id>
  <trn:currency>
    <cmdty:space>ISO4217</cmdty:space>
    <cmdty:id>USD</cmdty:id>
  </trn:currency>
  <trn:date-entered>
    <ts:date>2010-03-05 14:15:56 -0800</ts:date>
    <ts:ns>906362000</ts:ns>
  </trn:date-entered>
  <trn:description>Opening Balance</trn:description>
  <trn:splits>
    <trn:split>
      <split:id type="guid">235eb219e58e23b3f8943677837aed2c</split:id>
      <split:reconciled-state>n</split:reconciled-state>
      <split:value>88269/100</split:value>
      <split:quantity>88269/100</split:quantity>
      <split:account type="guid">e8361e7e7f1978bc9ce9ca22e75c2594</split:account>
    </trn:split>
    <trn:split>
      <split:id type="guid">77ec9dfc1c2d2ee7a86f67c24c6026e1</split:id>
      <split:reconciled-state>n</split:reconciled-state>
      <split:value>-88269/100</split:value>
      <split:quantity>-88269/100</split:quantity>
      <split:account type="guid">618b210a0c8d7a499ff0502b603e0827</split:account>
    </trn:split>
  </trn:splits>
</gnc:transaction>

So for one reason or another there is an invalid transaction in the data file. This transaction is lacking the mandatory trn:date-posted field.

The transaction is between the Opening Balances account and the Sears Credit Card.

Julie, how exactly are you entering this transaction ? There are many other transactions in the file that are just fine. So is there something that distinguishes this transaction from the others ?
Comment 7 Geert Janssens 2010-03-07 11:06:31 UTC
In any case it seems I was wrong about the quote in your path. If the error is reproducible in C:\GNUCash, the quote is obviously not the cause.
Comment 8 Geert Janssens 2010-03-09 18:23:12 UTC
Julie, how exactly are you entering this transaction ? There are many other
transactions in the file that are just fine. So is there something that
distinguishes this transaction from the others ?
Comment 9 Julie 2010-03-10 16:19:27 UTC
I'm not entering this in differently than the others.  I did not receive any kind of error when entering it.  For the new account with an opening balance I enter the opening balance on the second tab.

Since you said the error was between Opening Balances and Sears Card then I have a theory that the problem is with Opening Balances.  I have yet to test this since I have been rather busy.  But my plan is to create two new accounts, one with an opening balance (for an account created after the initial creations) and one without and see if that's the problem.
Comment 10 bugzilla25 2010-03-16 00:54:27 UTC
I have the same issue as Julie.  I don't know if this could possibly have anything to do with it, but I had installed Strawberry Perl in between the last time I used Gnucash successfully.   When I tried to open my gnucash account today and it failed I saw that my Strawberry Perl ran something in a dos window as Gnucash was loading as if Gnucash had called it.

Is that crazy?
Comment 11 Julie 2010-03-16 20:50:47 UTC
I tested my Opening Balances theory and it seems to be the problem.  I will continue entering data in a new account with opening balances and see what happens.

I don't have Strawberry Perl on my computer.
Comment 12 Jukka Zitting 2010-03-26 22:52:37 UTC
I can confirm Julie's theory. I recently started using GnuCash 2.2.9 (on Windows)
and didn't at first notice the opening balance tab in the new account creation
dialog. Once I did notice the tab and used it to enter the opening balances of
some new accounts, I'd start seeing the same parse error as reported above.

Thanks to this issue I was able to fix the troublesome file by manually entering
the missing trn:date-posted elements. Everything seems to work fine if I don't
use the opening balance tab, and instead enter the opening balance just like
any other transaction.
Comment 13 Julie 2010-03-26 23:05:43 UTC
Since my last comment I have been using GNUCash every day without any trouble by not entering the opening cash balance in the create a new account dialog.  Now that we have figured out this is more than likely the cause, hopefully it will be easier to fix the bug.  :-)  Thank you for your efforts.
Comment 14 Geert Janssens 2010-03-28 21:33:18 UTC
Thank you all for the feedback. I'll mark this as a valid bug report to be fixed.
Comment 15 Geert Janssens 2010-03-30 16:38:19 UTC
Alas, I can't reproduce this behaviour on my Windows Test machine...

I'm running Windows XP Home, Service Pack 3, Dutch version.

Could you provide me with very detailed steps of a way you can consistently reproduce the parsing error ?

Like:
- open a GnuCash data file
- choose "Create new account"
- enter this information (like what type, name, parent account,...)
- what do you enter on the opening balances tab
- ... anything you do until you get the parsing error.

And could you attach the gnucash.traceXYZABC file after the parsing error (see 
http://wiki.gnucash.org/wiki/Windows#Error_messages.2C_Trace_file to find this file) ?

I hope it's some specific combination of actions that results in this crash.
Comment 16 Jukka Zitting 2010-03-31 08:34:07 UTC
I boiled this down to the following steps:

1. Open GnuCash (I'm using 2.2.9 on Windows Vista)
2. Select File > New > New File
3. Use the default settings in the New Account Hierarchy Setup wizard
   (for me they are  "CHF" and "Common Accounts")
4. Select File > New > New Account
5. In the General tab, set Account name to "test" and Account type to "Bank"
6. In the Opening Balance tab, set Balance to 1000,00
   (comma is a decimal separator in my locale)
7. Select File > Save and save the file as "test.gnucash"
8. Select File > Open and try to open this same file
   -> "There was an error parsing the file ..."

I'll attach the resulting file where the troublesome transaction entry can
be found.

Note that I get the same result even when I cancel the New Account Hierarchy
Setup wizard in step 3 and use an empty accounts page instead.
Comment 17 Jukka Zitting 2010-03-31 08:35:39 UTC
Created attachment 157560 [details]
test.gnucash
Comment 18 Jukka Zitting 2010-03-31 08:43:30 UTC
Created attachment 157561 [details]
gnucash.trace file

Trace file from trying to open the above test.gnucash file.
Comment 19 Geert Janssens 2010-03-31 09:47:23 UTC
I still can't reproduce with your steps. On my system, the default currency is Euro. If I keep this, I get no problems. I also tried using CHF, but it still gives no parsing error.
The gnucash.trace file you attached gives the same information I already found in comment #6.

As I understand it, the post date is taken from the opening balance tab as well for some reason this step doesn't work on your system and does on others. So let's see if we can find out what's different there.

Can you do the following experiment for me:
- Run your steps up until step 5.
- In step 6, set the opening balance, take a screenshot of the opening balance tab and attach it to this bug.
- Then close close the new account dialog, save and quit GnuCash
- Attach the gnucash.trace file that was generated (BEFORE you restart GnuCash and run into the parsing error again).

Thanks.
Comment 20 Jukka Zitting 2010-03-31 10:08:40 UTC
Created attachment 157565 [details]
Screenshot of the Opening Balance tab
Comment 21 Jukka Zitting 2010-03-31 10:11:57 UTC
Created attachment 157566 [details]
Trace file covering the above steps 1-7

Trace file as requested. There's one suspicious-looking entry:

*   CRIT <GLib> g_date_to_struct_tm: assertion `g_date_valid (d)' failed

The date "31.3.2010" is what I get by default in the dialog,
i.e. I didn't change it.
Comment 22 Jukka Zitting 2010-03-31 10:16:29 UTC
BTW, the above date format is correct in my locale and it's also used elsewhere
in GnuCash. I use the same date format when entering normal transactions.
Comment 23 Geert Janssens 2010-03-31 10:29:21 UTC
Yes, I agree the date format should be valid. However, GnuCash clearly thinks otherwise (or more precisely, glib does) as shown by your latest trace file:

*   CRIT <GLib> g_date_to_struct_tm: assertion `g_date_valid (d)' failed

There is something with the date field in the opening balance tab.

I also noticed for example that in my case this field uses date format dd/mm/yyyy, while the rest of GnuCash uses dd.mm.yyyy.

I'm not sure yet what it is, but I believe this is where the problem starts.
Comment 24 Geert Janssens 2010-07-15 09:37:33 UTC
I have been looking on and off at this for a while now. The GnuCash code seems completely correct to me. It depends on a a call to the glib library to retrieve the date from the date field. This call shouldn't fail. The date field is supposed to guarantee that the date entered is proper. This guarantee doesn't seem to work 100% on Windows.

I notice that the development series of GnuCash (2.3.x) uses a more recent version of the glib library. Perhaps it has fixed the problem already. To test this, can you
* download GnuCash 2.3.14 from http://code.gnucash.org/builds/win32/trunk/
* uninstall GnuCash 2.3.9
* Make a backup of your .gnucash directory (this is probably a hidden directory) in c:\Documents and Settings\<username>
* install GnuCash 2.3.14
* Run your steps up until step 7.
* Then quit GnuCash
* Attach the gnucash-xyz.trace.log file that was generated, BEFORE you restart GnuCash (Note that 2.3.14 adds .log to the trace file's name)
* Then try to open GnuCash again and see if you still get the error.

Finally
* Uninstall GnuCash 2.3.14
* Restore your original .gnucash directory
* Install GnuCash 2.2.9

The steps with the .gnucash directory are not related to the problem, but this prevents the development version of GnuCash from interfering with some local settings in the stable version.
The uninstall of 2.2.9 is necessary because 2.3.14 won't start properly otherwise (it is installed on top of 2.2.9, but this isn't done completely cleanly, so it fails to start unless the old release is removed first).
Comment 25 John Dempsey 2010-07-22 18:05:14 UTC
I am based in the UK and have had the same problem while trialing 2.1.9.

Have tried on 2.3.14 and still the same.

I think I have isolated the cause. 

If when adding the opening balance on the opening balance tab you either enter the date with the calendar or by typing the date with four characters for the year then it is OK. If you type the year with just two characters then although it doesn't flag up an error, you get the passing error when restarting GNUCash.

So far this is 100% repeatable.
Comment 26 Geert Janssens 2010-08-05 08:51:24 UTC
Thank you very much. I think you have exactly pin-pointed the cause: if I only use 2 digits for the year, I can also reproduce this on my test machine.

As far as I can see, the bug is actually in libgnomeui, an external library used by GnuCash. But unfortunately it has ugly side effects in GnuCash.

The good news is that this means the opening balances tab is not completely unusable. I see two possible workarounds until the problem is fixed:
1. Use the dropdown menu ("Calendar" in English) to select a date
2. When entering a date manually, make sure you enter a 4-digit year
Comment 27 sean.culligan 2010-10-12 20:23:58 UTC
So how do I fix a file to be able to use it? I will keep note to only enter years as 4 digit, but how do I recover my existing file? TIA.
Comment 28 Geert Janssens 2010-10-14 12:57:30 UTC
There is no easy way from within GnuCash to recover your file, because it fails to open.

But if you don't mind manually editing an xml file, you can do as follows:
* Open a copy of your data file in a text editor (Wordpad on Windows, or emacs, kwrite,... on linux)
* If you only see garbage or get a warning the file is unreadable, that means it is still gzip compressed. In that case you have to rename the copy of your data file to <somename>.gz and use a suitable tool to uncompress that file (on linux you could use gunzip, on Windows I don't know off-hand which tool to use, you'll have to consult google)
* Anyway, try to open the uncompressed file in your text editor.
* You should see an xml file now.
* You will have to go through the xml file looking for transactions which are missing a <tr:date-posted> record.

If your file is big, this can look challenging, but on linux there's some help: to know which transaction you are looking for, you should start gnucash from the command line like:
gnucash <path/to/the/copy/of/your/data/file>

Like this, GnuCash should attempt to open the copy of your datafile. This will still fail, but it will print the invalid transaction on the command line. From this output, you can take the transaction's guid and search for that in your text editor.

Once you have found the invalid transaction, add a <tr:date-posted> record. For an example, just look at another transaction in the same file.

Save your changes and try to run GnuCash again. If it still fails, it should be printing you the next transaction that was invalid, and your can repeat the process.

Once all transactions are fixed, GnuCash should be able to open your corrected data file and you can continue to work.
Comment 29 Geert Janssens 2011-03-03 21:44:18 UTC
*** Bug 626910 has been marked as a duplicate of this bug. ***
Comment 30 Geert Janssens 2011-04-29 10:36:32 UTC
*** Bug 611020 has been marked as a duplicate of this bug. ***
Comment 31 Geert Janssens 2011-04-29 10:41:04 UTC
This problem has been fixed in the development version. I have replaced the date entry field on the opening balance tab with the same code as used in the register. Aside from fixing this 2-digit issue, this also adds keyboard navigation (+/- in combination with shift, alt or ctrl to jump one day, one month, one week or one year in the date field).

The fix will be available in the next major software release. Thank you for your bug report.
Comment 32 Geert Janssens 2012-02-01 10:50:34 UTC
*** Bug 669061 has been marked as a duplicate of this bug. ***
Comment 33 Geert Janssens 2012-06-25 20:29:03 UTC
Since GnuCash 2.6 may still be a while, I have fixed this for 2.4 as well in r22239.
Comment 34 John Ralls 2018-06-29 22:36:08 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=611853. Please update any external references or bookmarks.