Thanks for the report.  As you may have expected we need more information to help you :-)

What about error messages?  http://wiki.gnucash.org/wiki/Windows#Error_messages . 

Is your file compressed?  If you open it in an editor you can either read the xml or see binary data.  In the latter case please uncompress it using 7-zip and see whether that changes anything.

Once your file is uncompressed and you made a backup of the original, you can start modifying it with an editor, removing complete global xml elements until gnucash loads it again.  If you can track it down to some small portion, please attach that here.  Maybe you also find a way to reproduce the crash with an empty or small test file.

Last but not least you can also send me your file privately so I do that work for you :-)

There are no Gnucash error messages. 

It turns out the file is compressed, but I also tried an earlier saved version which was not compressed (9.34MB) I got the same failure. I unzipped my current file. It is now 10.069MB. Gnucash fails the same way. 

I have been chopping off transactions starting at the end of the file. It appears to be this transaction that makes it fail.

<gnc:transaction version="2.0.0">
  <trn:id type="guid">fa444113c4a2f3fde67ff8603cda7ac5</trn:id>
  <trn:currency>
    <cmdty:space>ISO4217</cmdty:space>
    <cmdty:id>USD</cmdty:id>
  </trn:currency>
  <trn:date-posted>
    <ts:date>1969-12-31 00:00:00 -0500</ts:date>
  </trn:date-posted>
  <trn:date-entered>
    <ts:date>2007-03-27 19:09:03 -0400</ts:date>
    <ts:ns>344892000</ts:ns>
  </trn:date-entered>
  <trn:description>Interest</trn:description>
  <trn:splits>
    <trn:split>
      <split:id type="guid">dcf18bf70569e6dad0a17cb530cbc3ee</split:id>
      <split:reconciled-state>n</split:reconciled-state>
      <split:value>9463/100</split:value>
      <split:quantity>9463/100</split:quantity>
      <split:account type="guid">580540231dc0de38087762a6def5350f</split:account>
    </trn:split>
    <trn:split>
      <split:id type="guid">d9d109d1426d00ccaef1742988ad8dfc</split:id>
      <split:reconciled-state>y</split:reconciled-state>
      <split:reconcile-date>
        <ts:date>2011-01-11 00:00:00 -0500</ts:date>
      </split:reconcile-date>
      <split:value>-9463/100</split:value>
      <split:quantity>-9463/100</split:quantity>
      <split:account type="guid">248c107c11928aba1ec9c2129ed267f2</split:account>
    </trn:split>
  </trn:splits>
</gnc:transaction>

Just in case it was the length of the file or what ever, I also left this transaction and removed earlier ones. If this one is in the file, it won't open (the few times I have tried). 

Does this help? 

Yep.  Thanks a lot!

Here is a bit more to the puzzle.

I tried to leave the questionable transaction in and remove a lot more (about 200K of file size) out. The file loaded.

On the other hand if I go back to the original 10,069KB uncompressed file and remove that one transaction (fa444113c4a2f3fde67ff8603cda7ac5), the file also loads. 

Do you have any suggestions about other things I can try? Do you want to see the file? 

Thanks for your help. 

One new thing I noticed which may be significant. 

If I change this line (the 8th line in the above transaction)
<ts:date>1969-12-31 00:00:00 -0500</ts:date>

to 
<ts:date>2007-02-31 00:00:00 -0500</ts:date>

The file opens. This is the only line with the (obviously incorrect) 1969 date. 

Maybe MS has a problem with the date....

Thanks again. 

Oh, I forgot to tell you about that work-around.  I am sorry for that.
Actually, the information you provided is enough to reproduce the bug and I will try to work on it.

I tried to reproduce this on a recent development build (r21371) and the crash no longer happens.

Things are not ok yet though. The 1969-12-31 00:00:00 -0500 date is still causing trouble.

Instead of crashing, it will now be replaced with a random date in the future.

So the core issue remains: how to deal with invalid dates properly ?

My guess would be to inform the user, but continue to work with a default date instead. The first allowed date would be my suggestion.

Oh, and if other devs want to look into this as well, I think the issue starts in function set_tran_date in src/backend/xml/gnc-transaction-vc.c:433

This function first tries to generate a time_t from the string found in the xml file. It calls the function dom_tree_to_timespec for that. That function has a sanity check to verify if the calculated time_t is not -1 (invalid time_t), but at present the calculated time in seconds is never -1, not even on the 1969-12-31 date. So the sanity check fails.

Result: a negative time in seconds is stored in the loaded transaction.

Should the sanity check have worked, then no date at all would be stored in the loaded transaction, which I suspect is even worse.

With today's SVN trunk, the error seems to have disappeared: There is no crash. An imported posted-date from 1969-12-31 appears as a txn in the (old-style) register at that very date. Inserting the txn snippet from above in a gnucash file will simply give a gnucash file with this txn at 1969-12-31.

Hence some of the date parsing work in recent months seem to have fixed this. Can someone else please confirm this as well?

My test system: Windows XP. I have created a small test file with one transaction dated 1969-12-30.

I first opened this test file in GnuCash 2.4.13. The date did get messed up in that version (as expected).

Next I opened the same file in today's nightly trunk build (2.5.2-2013-06-20). In this version the date appears just fine.

At least in the old register code. The new register code doesn't show the transaction at all. This however is a separated bug, unrelated to the date.

So I consider this one fixed. Thank you for pursuing this.

Good. We don't know who fixed it over the last months or years, but at least it is fixed.

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