GNOME Bugzilla – Bug 635859
Gnucash crashes on open when trying to load existing mysql database
Last modified: 2018-06-29 22:48:23 UTC
Created attachment 175314 [details] Backtrace from crash. On Fri, Nov 26, 2010 at 8:23 AM, Keith Bellairs <keith@bellairs.org> wrote: Just did a save as into mysql with 2.3.17 on f14. that worked fine until I closed gnc and then tried to open it again. it now crashes every time with a seg fault i try to start gnc . It did tell me it could not get the lock and i told it to start anyway. crash comes before gui opens. downloading the abrt tools to see if i can see what is happening.
Same but with sqlite backend. I open my xml format with 2.3.17, saved it as sqlite, then made changes and closed gnc. When I restarted, it crashed. I moved the file and restarted gnc, then tried to open the sqlite file. Crashed again. Fortunately, I had the logfiles. I replayed them on my xml file and recovered all my edits. I am using Windows XP SP3 32 bit English version.
Can you attach a gnucash.trace from a crashed session?
I set up a Fedora-14 VM to see if I could duplicate the crashes. Unfortunately, it didn't work out: It's working fine for me. That suggests that there's something that I don't use (which would include all of the business features) which is precipitating the crash.
*** Bug 634389 has been marked as a duplicate of this bug. ***
Keith Bellars and I have isolated the problem in his database to a couple of import-map-bayes slot entries with names like "foo//bar". Could you (Christoph) try 'select * from slots with name like "import-map-bayes/%//%"' and (from a copy) delete any matching records, then try loading it in gnucash again?
struggling: - where does gnucash store the crash trace logs under Windows? - can i use any sqlite client for windows to run that query on the sqlite backend file? thanks.
1. http://wiki.gnucash.org/wiki/Tracefile 2. I think so.
I've committed r19904, which fixes the double-/ (caused by having a trailing slash in a description fragment from the baysean analyzer that matches transactions to accounts during import. It's a far-from-ideal solution, but I can't do the Right Thing just now for fear of introducing regressions. Cristoph, can you build a current svn and see if it fixes your crash too? If it does, I'll close this bug and open a new one to fix slots for the next release.
(In reply to comment #6) > struggling: > > - where does gnucash store the crash trace logs under Windows? > - can i use any sqlite client for windows to run that query on the sqlite > backend file? > > thanks. I don't think I answered your question correctly. You're looking for a crashdump, and I understand that the Windows Gtk lashup doesn't write any. As for sqlite, there's a program that comes with the distribution called "sqlite" which is a shell for querying databases. I thought that that's what you were talking about... but I think that anything that lets you run arbitrary queries against a sqlite3 database will work. If you can't do an svn build, don't worry, I can't get it to work on Windows either. Just download tomorrow's nightly build from http://code.gnucash.org/builds/win32/trunk/
(In reply to comment #8) > I've committed r19904, which fixes the double-/ (caused by having a trailing > slash in a description fragment from the baysean analyzer that matches > transactions to accounts during import. It's a far-from-ideal solution, but I > can't do the Right Thing just now for fear of introducing regressions. > > Cristoph, can you build a current svn and see if it fixes your crash too? > > If it does, I'll close this bug and open a new one to fix slots for the next > release. John - I checked your fix for "//" in SQLITE3 with the following build: GnuCash 2.3.17 development version Built 2010-12-05 from r19910 Did a Save As, Quit, Open and all worked fine. Added a transaction, quit and opened and all is good. Your fix is solid for this bug and my environment. Keith
I have also tested on identical xml saved as mysql and it works, too (as expected). Slightly off topic, the sqlite version completes loading user data in about 10 seconds. The mysql version takes 55 sec. Environment is F14 x86_64 BTW.
Sqlite is bound to be faster than a server-based backend: It's just intermediating normal file access with a linked-in library, while the mysql backend is shipping the query off to another process, so there are at least two context switches. Add to that that unless you have enough memory to keep both in memory, there will be a bunch of page faults for every query... and even if you do have plenty of memory, it will still cause at least two cache flushes. The problem is compounded, of course, by the huge mismatch between the design of the query object framework (which is XML-centric) and the relational data model. It means that there are lots of queries for small amounts of data, which is joined in Gnucash instead of in the database.
now also tested on postgres - success tests were run on dual core amd w 4GB mem, so memory page faults not an issue. totally understand mismatch issue. NOTE: build r19910 does not seem to clear the gnclock in postgres. Has this been seen?
Hi, I cannot run build on my own (no build environment set up here), but will download and test r19910 nightly build once it becomes available.
(In reply to comment #13) > now also tested on postgres - success > > tests were run on dual core amd w 4GB mem, so memory page faults not an issue. > > totally understand mismatch issue. > > NOTE: build r19910 does not seem to clear the gnclock in postgres. Has this > been seen? Yes, Bug 635926 as well as a report on the dev list. Fixed today.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=635859. Please update any external references or bookmarks.