Gnucash crashing on startup

[John Ralls]

> On Jun 9, 2017, at 2:05 AM, Okkie <gnucash at okkie.nu> wrote:
> 
> 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?

Hmm. That shows an error in the SQL date conversion: 1970-01-01 is obviously not 0000-00-00. It turns out that before the 2038 bug rewrite time_t 0 and negative time_ts were considered invalid dates and deliberately set to NULL in the SQL backend. Somewhere along the line MySql seems to have written those NULLs out as 0000-00-00. I've removed that code from the SQL backend because time_t 0 (now time64 0) is a perfectly legitimate date.

I've also now fixed the crash that I was supposed to have done for 2.6.16, so any date before the date system's minimum gets converted to 1970-01-01 00:00:00 UTC and any later than the date system's maximum gets clamped at the date system maximum.

Regards,
John Ralls