GNOME Bugzilla – Bug 724995
Gnucash crashes due to assertion failed when opening sqlite file
Last modified: 2018-06-29 23:27:11 UTC
Once I save my current XML datafile as Sqlite datafile, GnuCash crashes due to assertion failed when starting GnuCash next time. I think this is due to unexpected data saved or assertion check difference for Sqlite datafile. How can I identify the data causing assertion failed? I can use sqlite3 for query. Please let me know some SQLs. Stack trace is as follows. Missing separate debuginfos, use: debuginfo-install gnucash-2.6.1-1.fc20.x86_64 (gdb) r Starting program: /usr/bin/gnucash [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib64/libthread_db.so.1". [New Thread 0x7fffd3f28700 (LWP 4126)] [New Thread 0x7fffd3727700 (LWP 4127)] Detaching after fork from child process 4147. [New Thread 0x7fffcbd00700 (LWP 4148)] Found Finance::Quote version 1.20 ** gnc.backend.sql:ERROR:gnc-transaction-sql.c:215:load_single_split: assertion failed: (pSplit == xaccSplitLookup( &split_guid, be->book )) Program received signal SIGABRT, Aborted. 0x00007ffff2fbcc39 in raise () from /usr/lib64/libc.so.6 (gdb) bt
+ Trace 233224
The actual assertion message should be the last line in /tmp/gnucash.trace. What is it?
This is the contents of it. Looks like it doesn't contain enough info. $ cat /tmp/gnucash.trace * 00:28:19 WARN <gnc.python> Unable to initialize Python module (unable to open /usr/share/gnucash/python/init.py)
You're right, but I see that it's in your error report just before the trace. D'oh. Something's going wrong with creating a split, but I don't immediately see what.
Is it possible to provide a SQL to find the record hitting the assertion fail? assertion failed: (pSplit == xaccSplitLookup( &split_guid, be->book )) I have both XML datafile and SQLite datafile. Once I find the split record hitting the condition in SQLite datafile, I can show you the original XML record by comparing.
Maybe, but I don't yet know enough to say. Are you able to build GnuCash from source with debugging symbols? That would allow you to see the GUID causing the crash, which you could easily find in both the XML and SQLite files. If that's not possible and the SQL file isn't too big (<10MB), you could email it to me. You can see my email address by hovering over my name.
Successfully compiled from source code and I found something. I put following 2 lines at gnc-transaction-sql.c:214, built again, and tried loading my SQLite datafile. (void)guid_to_string_buff( guid, guid_buf ); (void)guid_to_string_buff( &split_guid, split_guid_buf ); I got following results. <last 5 lines only> guid=824c692697f0a2d58e1aa5719c019cd3, split_guid=824c692697f0a2d58e1aa5719c019cd3 guid=ec7d3bf30f2c48332eac9c0077a0d33d, split_guid=ec7d3bf30f2c48332eac9c0077a0d33d guid=00000000000000000000000000000000, split_guid=00000000000000000000000000000000 ** gnc.backend.sql:ERROR:gnc-transaction-sql.c:221:load_single_split: assertion failed: (pSplit == xaccSplitLookup( &split_guid, be->book )) And actually there is guid=00000000000000000000000000000000 record in SQLite data file. $ sqlite3 d.gnucash SQLite version 3.8.3 2014-02-03 14:04:11 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> select * from splits where guid='00000000000000000000000000000000'; 00000000000000000000000000000000|5178c3b987c69282f65987dcd695bbda|2bf4bf8753c79229e6903fc65ad48665|||n||-3000|1|-3000|1| This record may be the cause. When I saved as SQLite datafile, the record was created... Will try to find original record.
Tiny correction. What I added at gnc-transaction-sql.c:214 was as follows. (void)guid_to_string_buff( guid, guid_buf ); (void)guid_to_string_buff( &split_guid, split_guid_buf ); printf("guid=%s, split_guid=%s\n", guid_buf, split_guid_buf);
Found original XML record. <gnc:transaction version="2.0.0"> <trn:id type="guid">5178c3b987c69282f65987dcd695bbda</trn:id> <trn:currency> <cmdty:space>ISO4217</cmdty:space> <cmdty:id>JPY</cmdty:id> </trn:currency> <trn:date-posted> <ts:date>2008-12-13 00:00:00 +0900</ts:date> </trn:date-posted> <trn:date-entered> <ts:date>2010-07-17 14:45:12 +0900</ts:date> </trn:date-entered> <trn:description>ガソリンスタンド</trn:description> <trn:splits> <trn:split> <split:id type="guid">ec7d3bf30f2c48332eac9c0077a0d33d</split:id> <split:reconciled-state>n</split:reconciled-state> <split:value>3000/1</split:value> <split:quantity>3000/1</split:quantity> <split:account type="guid">8e65af6ece104e583538d7da9ace24e1</split:account> </trn:split> <trn:split> <split:id type="guid">00000000000000000000000000000000</split:id> <split:reconciled-state>n</split:reconciled-state> <split:value>-3000/1</split:value> <split:quantity>-3000/1</split:quantity> <split:account type="guid">2bf4bf8753c79229e6903fc65ad48665</split:account> </trn:split> </trn:splits> </gnc:transaction>
Actually above record is not shown on gnucash spreadsheet. I think the record has been incorrectly created at some point. After I removed the transaction tag, I could save and reopen SQLite datafile. But I can say 2 things. - if split:id = 00000000000000000000000000000000 is in transaction, SQLite or MySQL data will cause crash. - gnucash should have some logic to prevent this situation.
Good detective work! Any idea whether that transaction was made from the UI or from an import, and if the latter, what kind? Would you have been using 2.2.9, which was the current stable release, in 2010?
I may be the former as I've never imported to the account. I've been maintaining my XML data file for 8 years with the latest stable version by Fedora Linux. I often do "yum update", so the record should be created by the current stable release as you said.
I've pushed 37d7a38, which raises an error instead of asserting and corrects the GUID when writing to the database. This will be in 2.6.3.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=724995. Please update any external references or bookmarks.