GNOME Bugzilla – Bug 726891
segmentation fault on session.end(): "corrupted double-linked list"
Last modified: 2018-06-29 23:28:45 UTC
Created attachment 272643 [details] sample script to reproduce the crash I have a simple Python script to put some accounts in a new book. It opens two sessions but when I close a session I get a segfault. It seems to be somewhat dependent on the number/type of transactions in the gnucash file. With my real book keeping files I can reproduce the crash every time. I attached a sample gnucash file which I (hopefully) cleaned of all sensitive data. It doesn't trigger the crash every time but maybe every 10th time I call the Python script. (I'm aware that the assertion "qof_book_is_readonly: assertion 'book != NULL' failed" is bad and I should probably do something about it. However gnucash should never crash.)
Created attachment 272644 [details] sample gnucash file
Well, GnuCash doesn't crash, your script does. The problem is that getting the root account on a new file creates a new root account, because there wasn't already one, and creating an account fires off xaccAccountCommitEdit. Since you didn't specify an xml file in your new file url, it creates a sqlite3 database file by default, and in the SQL backends commits flow to the backend so that they're immediately written out. But to do the commit, the code wants to get the stored book from the backend, and that's only set in a load operation. There are two problems there: First, the author of Session.__init__() calls qof_session_load() only if it's *not* a create, so you'd have to call it yourself in your script. Second, the SQL backend's load will create a new database when it's supposed to, but it doesn't set some internal version information so it immediately raises an error and the error handler closes and frees the backend. Then you come along in the next line and close the session, which tries to free the already-freed backend, and it crashes. 5d1d6109 fixes both problems.
Thank you very much for your fixes. (In reply to comment #2) > Well, GnuCash doesn't crash, your script does. Just so I understand it: When you wrote "GnuCash doesn't crash, your script does." then "GnuCash" to you is the gui app, right while "script" refers to GnuCash Python bindings + my example code, right? If I understand your comment + the commit correctly there is nothing inherently wrong with the Python script I attached but the bug is in the Python bindings?
GnuCash is indeed the GUI application, written in C and Scheme. The python bindings are provided as a minimally supported convenience for extending GnuCash. We make no representations that the API in those bindings is at all coherent: It grew over time to support features of the GUI application and often requires careful study of the C sources to use correctly. Yes, there is nothing inherently wrong with the script when used with the change I pushed to master yesterday. Before that change, you need to call a function which sets the version data in the SQL database (e.g. session.sync_all()) and then session.load() before calling session.book.get_root_account() *or* specify in your output filename creation that it should create an xml file by naming it 'xml:' + source_filename + '-new', which avoids the bug.
Unfortunately this fix for sqlite3 breaks opening a new xml file via the python bindings. Running the simple_business_create.py file with as argument xml:///<path-to-new>/file.gnucash results in this error trace: * 18:16:39 WARN <gnc.backend> [gnc_xml_be_load_from_file()] File not any known type Traceback (most recent call last):
+ Trace 234366
s = Session(argv[1], is_new=True)
self.load()
self.raise_backend_errors(function.__name__)
errors )
I have reopened the bug for further investigation.
I have somewhat refined John's fix to properly cope with some subtle differences between the xml and the sql backends. When creating a new data store - of type xml, the new store can't be loaded upfront - of type sql, the new store has to be loaded before writing to it This is now reflected in the python bindings. The fix will appear in gnucash 2.6.5.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=726891. Please update any external references or bookmarks.