After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 726891 - segmentation fault on session.end(): "corrupted double-linked list"
segmentation fault on session.end(): "corrupted double-linked list"
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Python Bindings
2.6.2
Other Linux
: Normal normal
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
Depends on:
Blocks:
 
 
Reported: 2014-03-22 16:56 UTC by Felix Schwarz
Modified: 2018-06-29 23:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sample script to reproduce the crash (439 bytes, text/plain)
2014-03-22 16:56 UTC, Felix Schwarz
Details
sample gnucash file (1.91 KB, application/x-gnucash)
2014-03-22 16:58 UTC, Felix Schwarz
Details

Description Felix Schwarz 2014-03-22 16:56:50 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.)
Comment 1 Felix Schwarz 2014-03-22 16:58:55 UTC
Created attachment 272644 [details]
sample gnucash file
Comment 2 John Ralls 2014-03-24 21:17:01 UTC
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.
Comment 3 Felix Schwarz 2014-03-25 08:27:44 UTC
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?
Comment 4 John Ralls 2014-03-25 14:34:38 UTC
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.
Comment 5 Geert Janssens 2014-11-23 17:17:11 UTC
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):
  • File "src/optional/python-bindings/example_scripts/simple_business_create.py", line 73 in <module>
    s = Session(argv[1], is_new=True)
  • File "/home/janssege/Development/Installs/gnucash-f20-maint/lib64/python2.7/site-packages/gnucash/gnucash_core.py", line 105 in __init__
    self.load()
  • File "/home/janssege/Development/Installs/gnucash-f20-maint/lib64/python2.7/site-packages/gnucash/gnucash_core.py", line 144 in new_function
    self.raise_backend_errors(function.__name__)
  • File "/home/janssege/Development/Installs/gnucash-f20-maint/lib64/python2.7/site-packages/gnucash/gnucash_core.py", line 122 in raise_backend_errors
    errors )
gnucash.gnucash_core.GnuCashBackendException: call to new_function resulted in the following errors, ERR_FILEIO_UNKNOWN_FILE_TYPE


I have reopened the bug for further investigation.
Comment 6 Geert Janssens 2014-11-24 10:58:40 UTC
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.
Comment 7 John Ralls 2018-06-29 23:28:45 UTC
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.