Gnucash segmentation fault - Postgresql

[John Ralls]

On May 5, 2012, at 3:30 PM, h0l0fernes wrote:

> > > Thank You John for hint! My problem seems to be indeed very similar to bug https://bugzilla.gnome.org/show_bug.cgi?id=674862 , I played a little with Mortgage Wizard, but this is quite a long ago if I recall correctly. I have posted comment in this bug thread with gdb stacktrace from my case, as you suggested. 
> > > Actually, in my case, I could try to remove mortgage wizard transactions from psql, if you could direct me where to search for such transactions? Gnucash schema tables looks very complicated for me, and I couldn't find clear description of how this tables are organized in Postgresql.
> > >  
> > > Thank you for help!
> > > Krzysiek
> >  
> > [1] https://bugzilla.gnome.org/show_bug.cgi?id=674862
> > 
> > The guy who found this problem originally did manage to fix his database [1], but it apparently wasn't easy. If you look at the end of your trace file (should be /tmp/gnucash.trace on Linux) you'll see the offending account numbers to try to find and remove from your database.
> > 
> > Regards,
> > John Ralls
> > 
> > [1] http://gnucash.1415818.n4.nabble.com/Gnucash-crashes-when-loading-user-data-from-mysql-tp4584032p4586884.html
> 
> Thank you for pointing me to /tmp/gnucash.trace file!  In this file, after crash I have:
>  
> * 23:49:53  WARN <gnc.app-utils> /home/krzys/.gnucash/config-1.8.auto:13:15: While evaluating arguments to gnc:lookup-option in expression (gnc:lookup-option gnc:*options-entries* "__new_user" ...):
> /home/krzys/.gnucash/config-1.8.auto:13:15: Unbound variable: gnc:*options-entries*
> In /home/krzys/.gnucash/config-1.8.auto:
>   13: 0* (let* ((option #)) ((lambda # #) option))
>   13: 1* [gnc:lookup-option ...
> * 23:50:05  WARN <qof.engine> [gnc_iso8601_to_timespec_gmt()]  mktime failed to handle daylight saving: tm_hour=0 tm_year=-2012 tm_min=0 tm_sec=0 tm_isdst=-1 for string=-112-31-23 00:00:
> * 23:50:05  CRIT <qof.engine> [gnc_iso8601_to_timespec_gmt()]  unable to recover from buggy mktime
> * 23:50:05  WARN <qof.engine> [gnc_iso8601_to_timespec_gmt()]  mktime failed to handle daylight saving: tm_hour=0 tm_year=-2011 tm_min=0 tm_sec=0 tm_isdst=-1 for string=-111-30-22 00:00:
> * 23:50:05  CRIT <qof.engine> [gnc_iso8601_to_timespec_gmt()]  unable to recover from buggy mktime
> * 23:50:05  WARN <qof.engine> [gnc_iso8601_to_timespec_gmt()]  mktime failed to handle daylight saving: tm_hour=0 tm_year=-2011 tm_min=0 tm_sec=0 tm_isdst=-1 for string=-111-30-23 00:00:
> * 23:50:05  CRIT <qof.engine> [gnc_iso8601_to_timespec_gmt()]  unable to recover from buggy mktime
> * 23:50:05  WARN <qof.engine> [gnc_iso8601_to_timespec_gmt()]  mktime failed to handle daylight saving: tm_hour=0 tm_year=-2011 tm_min=0 tm_sec=0 tm_isdst=-1 for string=-111-30-22 00:00:
> * 23:50:05  CRIT <qof.engine> [gnc_iso8601_to_timespec_gmt()]  unable to recover from buggy mktime
> * 23:50:05  WARN <qof.engine> [gnc_iso8601_to_timespec_gmt()]  mktime failed to handle daylight saving: tm_hour=0 tm_year=-2012 tm_min=0 tm_sec=0 tm_isdst=-1 for string=-112-31-22 00:00:
> * 23:50:05  CRIT <qof.engine> [gnc_iso8601_to_timespec_gmt()]  unable to recover from buggy mktime
> * 23:50:05  CRIT <GLib> g_date_new_dmy: assertion `g_date_valid_dmy (day, m, y)' failed
>  
> It seems, that my problem is not related to Mortgage Wizard, but to scheduled transactions. I am 100% sure that I have a few of scheduled transactions set for ~28th of every month, which could cause problems with February.
> Google shows that I am not alone (http://gnucash.1415818.n4.nabble.com/2-3-3-saving-to-postgresql-causes-zombie-scheduled-transactions-td1449401.html). Nonetheless I couldn't find in bugzilla related bug.
> Again, It seems that I need to remove a few of scheduled transactions from Postgres, and then will be able to use Gnucash again. I am looking for documentation, where is described how scheduled transactions are stored in Postgres database..
> Maybe I should write an email on gnucash-devel?
> I wonder If I would remove everything from public.schedxactions table, then it would be enough? I will try this tomorrow.

The only documentation is the SQL wiki page [1] and the attendant ERD.

Those dates look seriously malformed, and the field that's causing the error is start_date in schedxactions. Try a 
SELECT guid, start_date FROM schedxactions;
and look through them to see if any (or all) of the date fields look bad. They should be of the form YYYYMMDD. The proximate cause of the crash itself is obvious enough: Unchecked dereferencing of a NULL pointer. *That* I can fix.

Regards,
John Ralls

[1] http://wiki.gnucash.org/wiki/SQL