Gnucash crashing on startup

[Okkie]

On 06/09/2017 01:50 AM, John Ralls wrote:
>> On Jun 8, 2017, at 7:56 AM, Okkie <gnucash at okkie.nu> wrote:
>>
>> [...]
>>
>> The difference / extra info here is:
>>
>> * gnucash did not crash. I shut down the previous version gracefully.
>> * This particulair transaction has been there for almost 12 years now.
>> * It is the very first transaction in this particular account.
>> * A quick look in a backup from 6 month's ago also shows: post_date:
>> 0000-00-00 00:00:00
>> * This never caused trouble while starting up before.
>>
>> So.. maybe it is a regression issue that may bite others too?
> Not exactly a regression. GnuCash should never have accepted a transaction with a post date from the reign of Octavian, though crashing isn’t an acceptable response either. 

Hehe. Maybe I shouldn't call it a regression, but none of the previous
versions dumped core on this entry. What makes matters worse is that it
needs a start from the command line to see if there's a useful error. A
GUI-only user only sees a splash screen that disappears after a while. And
even with the error, you need to have quite some skills to find the cause.
Thank you, Sahib Jakhar for finding it and posting it to this list! Saved me
a lot of time!

Maybe Sahib's first crash was not in any way related to this entry, but just
a trigger to start up into the new version. Sahib, are you also running
Ubuntu? Can you check in /var/log/apt/ if gnucash got upgraded during the
uptime of the session that eventually crashed?

>From my history I found the following updates:

2017-01-30  gnucash 1:2.6.12-1
2017-05-29  gnucash 1:2.6.16-1~getdeb1

The .12 version was restarted a few times and was still running for a few
weeks when I restarted the computer and started .16 for the very first time.



> How long ago did you switch to the SQL backend? That wasn’t available in 2005. I don’t suppose you have any of the old XML files around to see if the transaction was actually created with no post date.

Well, sometimes not cleaning up can be a good thing. Apparantly I still have
the backup from before the conversion hanging around in a subdirectory.

I migrated in december 2013, and in the last XML I see this next to the same
guid:

  <trn:date-posted>
    <ts:date>1970-01-01 00:00:00 +0100</ts:date>
  </trn:date-posted>
  <trn:date-entered>
    <ts:date>2005-09-09 16:21:36 +0200</ts:date>
  </trn:date-entered>

So even then, there was already a zero date (0s since the epoch) in this
transaction.

Does this help in any way?

Regards,
Oscar