Gnucash segmentation fault - Postgresql

[h0l0fernes]

> > 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.

Regards,
Krzysiek