GNOME Bugzilla – Bug 674862
Gnucash crashes after creating a new SX using the Mortgage Wizard and SQL Backend
Last modified: 2018-06-29 23:08:28 UTC
Created attachment 212867 [details] Tracefile and MySQL DB dump Describe the problem: After creating a new SX using the Mortgage Wizard, if you are using the MySQL Backend, Gnucash is not able to run again. When you create the SX you can still work with Gnucash, but after closing it, when you try to open it again it crashes always. The message from Windows is just that gnucash has crashed and will be terminated. The error in the Trace log file: * 12:25:56 INFO <gnc.account> [xaccAccountRecomputeBalance] acct=abf51b2b12142ec572094df4918c2429 starting baln=0/1 * 12:25:56 CRIT <GLib> g_date_new_dmy: assertion `g_date_valid_dmy (day, m, y)' failed * 12:25:56 CRIT <GLib> g_date_valid: assertion `d != NULL' failed Steps to reproduce: - Create a new book: During the Wizard select common, fixed assets and mortgage accounts. Also put 200.000,00€ in the liabilities:mortgage against the assets:fixed:home as the opening balance. - Store the new created book with the MySQL backend. - Run the Mortgage Wizard (leave default values if not indicated a specific value): - First screen: - Loan Account: liabilities:mortgage (where you have put the 200.000,00€) - Amount: 200000,00 - Interest: 2,487% - Start date: 2012-05-01 - Length: 480 months - Second screen: Nothing to select here, leave defaults (everything unchecked) - Third screen: - Pay from: select a paycheck account from assets. - Interest to: select the expenses:mortgage interest account. - Frequency: Monthly - Start: 2012-05-01 - Every month, First day of month, without changes in weekends. - Finish the wizard, save your book and close gnucash. - Open gnucash - Insert password of the MySQL database - Crashes when loading user data - Does this happen every time? Yes Environment: - Windows 7 - MySQL Server 5.5.17 - Gnucash 2.4.10 Attachments (in a zip file): - Gnucash Tracefile running with '--debug' - MySQL dump of the crashing Database: this database just contains the openning entry and the crashing SX. Additional Information: If you use the XML data store this error is not happening there. If you create the SX using the XML data store gnucash will not crash. But if you create the SX using the XML data store, and after that you "Save As" the book and save it as MySQL, then when you try to open the MySQL book it will crash, however the XML one will open correctly.
Moved to SQL Backend component, since I think it is more accurate for this issue.
Well, I finally replicated it, but it only happens on Windows and not only does it not crash with the XML backend, it also works fine with SQLite3. I'll check with Postgresql too just to be sure, but it's starting to smell like a MySQL-on-Windows issue.
Same problems with Postgres, again only on Windows.
It seems that I have very similar problem with Gnucash 2.4.10 on Linux (Kubuntu 12.04) with Postgresql. John Ralls asked me in this mail list: http://lists.gnucash.org/pipermail/gnucash-user/2012-May/044670.html to describe my problem here. I may have Mortgage Wizard created transactions, because I play a little with this option, although I am not 100% sure, because this was quite a long ago. Below I have posted gdb stacktrace from my case (Gnucash 2.4.10 installed from source), as John suggested. #########stacktrace########################### (gdb) continue Continuing. [New Thread 0x7fae768eb700 (LWP 31811)] Program received signal SIGSEGV, Segmentation fault. xaccSchedXactionSetStartDate (sx=0x151eaa0, newStart=0x0) at SchedXaction.c:591 591 sx->start_date = *newStart; (gdb) bt
+ Trace 230182
##################################### 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
I've committed to trunk (not yet backported) some sanity checks in the SX date functions to prevent crashes. Not really a complete answer, because the backend is still storing bogus date strings somehow.
My problems was caused by improper datestyle in Postgresql database, and was not related to Mortgage Wizzard. The full description could be found at: http://lists.gnucash.org/pipermail/gnucash-user/2012-May/044723.html You could remove my comments, as they are not relevant to this thread. Best Regards, H.
Well, I can't remove your comments anyway, but it turns out that your problem is indeed relevant. The sanity checks do prevent the crash in both cases, but don't really fix the root cause of the problem. In the case of the mortgage wizard, the problem is that libdbi returns a time_t, which is subject to the 2038 bug. The 40-year mortgage writes an end-date past 2038, and the returned time_t is -1. The reason it crashes only in Windows is that on Linux and MacOSX, gmtime(-1) returns {tm_sec = 59, tm_min = 59, tm_hour = 23, tm_mday = 31, tm_mon = 11, tm_year = 69, tm_wday = 3, tm_yday = 364, tm_isdst = 0, tm_gmtoff = 0, tm_zone = 0xb6d1525c "GMT"}, the mingw implementation returns garbage: {tm_sec = 122599504, tm_min = 1751162088, tm_hour = 89774067, tm_mday = 89788426, tm_mon = 0, tm_year = 1973917914, tm_wday = 1571828185, tm_yday = 55110248, tm_isdst = 2685208}. GDate can digest the former but returns a NULL for the latter -- which is what precipitates the crash. So I've committed and backported a fix that works around the MinGW bug and backported the earlier change which further guards against NULL GDates. That correct the immediate problem of this bug, but to fix the underlying problem the date extraction will have to be rewritten to use dbi_result_get_string() and parse the result.
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report. r23174 trunk, backported to 2.4 in 23177. Note that 2.4 doesn't have the rewrite of gnc-date to make it 2038 safe. That will be released in Gnucash 2.6. I also filed a bug upstream with libdbi: https://sourceforge.net/p/libdbi/bugs/15/
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=674862. Please update any external references or bookmarks.