GNOME Bugzilla – Bug 764871
Crash starting gnu cash
Last modified: 2018-06-29 23:48:27 UTC
OS: Ubuntu 14.04 64-bit MySQL database on another machine The crash does not occur if there is the lock present from a previous crash and I tell it to open the database read-only. Running under gdb, I get the UI pane about adding transations. Sometimes I get a pop-up that says "Invalid Transaction" and some unprintable characters.
jch@kismet[521]:~$ gdb gnucash GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from gnucash...(no debugging symbols found)...done. (gdb) c The program is not being run. (gdb) r Starting program: /usr/bin/gnucash [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffdba31700 (LWP 2987)] [New Thread 0x7fffdb230700 (LWP 2988)] [New Thread 0x7fffd9a2b700 (LWP 2991)] Found Finance::Quote version 1.18 [New Thread 0x7fffb2094700 (LWP 3021)] [Thread 0x7fffb2094700 (LWP 3021) exited] *** Error in `/usr/bin/gnucash': double free or corruption (out): 0x0000000002e87260 *** Program received signal SIGABRT, Aborted. 0x00007ffff5a31cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) where
+ Trace 236173
This time with symbols: jch@kismet[524]:~$ gdb gnucash GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from gnucash...Reading symbols from /usr/lib/debug/.build-id/cf/b382061b2f465013eeb6f5974e2540f07e6e2c.debug...done. done. (gdb) run Starting program: /usr/bin/gnucash [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffdba31700 (LWP 7262)] [New Thread 0x7fffdb230700 (LWP 7263)] [New Thread 0x7fffd9a2b700 (LWP 7266)] Found Finance::Quote version 1.18 [New Thread 0x7fffb2094700 (LWP 7290)] [Thread 0x7fffb2094700 (LWP 7290) exited] *** Error in `/usr/bin/gnucash': double free or corruption (out): 0x0000000002e8f2c0 *** Program received signal SIGABRT, Aborted. 0x00007ffff5a31cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) where
+ Trace 236174
Created attachment 325693 [details] gnucash.trace
Created attachment 325694 [details] gnucash.trace with --debug and --extra
I think I've found the error. Can you show a sanitized version of the defective SX so that I can try to reproduce the crash and see if I have fixed it?
Created attachment 327256 [details] Screen shot John, Here is a screenshot of the scheduled transactions page. Let me know if you want more detail on any of them. Is there a better way than a screen shot? Thanks. Jeff P.S. Sorry for the delay, FIRST Robotics Champs got in the way.
Sorry for my delay, I was away last week. I need the Template Transaction for the problem transaction. You can either make a screenshot or just describe it. If you can't figure out which of the three SXes is causing the problem describe or make screenshots of all three.
Created attachment 327839 [details] Template 1 of 3
Created attachment 327840 [details] Template 2 of 3
Created attachment 327842 [details] Template 3 of 3
Screenshots of the templates for all three schedule transactions I have are attached.
No. 2 seems in the screenshots to have blank debit/credit entries, is that real? BTW, it looks like #1 is moving money from Assets:HSA to Income:Employer Contribution. That seems backwards.
Yes, #2 just creates the entry for interest, I fill in the amounts when I look them up. I've been using this one for years. #1 could be backward, it also might be the one causing the crash as it only runs quarterly. I created it earlier this year.
We finally have a Windows nightly build to test on: http://code.gnucash.org/builds/win32/maint/gnucash-2.6.12-2016-05-17-git-c1ad615+-setup.exe
(In reply to John Ralls from comment #14) > We finally have a Windows nightly build to test on: > http://code.gnucash.org/builds/win32/maint/gnucash-2.6.12-2016-05-17-git- > c1ad615+-setup.exe My sympathies. Anything for Linux?
Sigh. Sorry, I put that on the wrong bug. Are you able to build? I can give you a patch to try.
I can't create an SX that will raise the error; I suspect that you have a malformed SX saved with a version of GnuCash from before the fixes to the SX edit code that protect against creating such bad SXes. I've fixed the mistake pointed to by the stack trace and pushed it. If you can use Fedora 21, 22, or 23 RPMs, nightly builds for each should show up around 05:05Z tomorrow at https://copr-be.cloud.fedoraproject.org/results/gjanssens/gnucash-maint/. You'll need to go to the appropriate version directory and find the right nightly build.
I use Ubuntu 14.04 at the moment. So I'll either need to spin up a Docker container or build for 14.04. My database is in SQL, would the results of some queries help you recreate?
Well, the results of SELECT * FROM slots WHERE name LIKE "%formula"; would tell me which one's wrong and why. I could try hand-editing a test file to inject a similar error.
Created attachment 328341 [details] formulas
Thanks. You've got a single-split SX in there, that's likely the real problem. DELETE FROM slots WHERE obj_guid = "bd7a3076fe8c4bdb8c759eeb490124a8" OR guid_val = "bd7a3076fe8c4bdb8c759eeb490124a8"; will remove it and will probably let you start GnuCash 2.6.12. For absolute safety first do that query with SELECT * instead of DELETE and check the results.
John, I did that and still got the crash. I then deleted all the scheduled entries (DELETE FROM slots WHERE name LIKE "%forumula";) and *still* get a crash. See the trace here: jch@kismet[509]:~$ gdb gnucash GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from gnucash...Reading symbols from /usr/lib/debug/.build-id/cf/b382061b2f465013eeb6f5974e2540f07e6e2c.debug...done. done. (gdb) run Starting program: /usr/bin/gnucash [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffdb825700 (LWP 24240)] [New Thread 0x7fffdacda700 (LWP 24244)] [New Thread 0x7fffda4d9700 (LWP 24245)] Found Finance::Quote version 1.18 [New Thread 0x7fffbf6b6700 (LWP 24308)] [Thread 0x7fffbf6b6700 (LWP 24308) exited] *** Error in `/usr/bin/gnucash': free(): invalid pointer: 0x0000000002f29420 *** Program received signal SIGABRT, Aborted. 0x00007ffff5a31cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) where
+ Trace 236275
Is it still worth trying a nightly build on Fedora? I tried building the sources on 14.04, but I have too many version conflicts with required packages.
I've successfully recreated your crash and confirmed that my fix prevents it, so there's no real need for you to set up a Fedora VM or build yourself. DELETE FROM slots WHERE name LIKE "%formula"; doesn't delete anything that would raise the error. It turns out I was mistaken about a single-legged SX, it happily creates an imbalance entry without complaint. If the DELETE query I gave you didn't work either then you don't have a bad account GUID either; that was my next guess and what I used to check that the crash is fixed. If you crash it in the debugger again and then f 5 p (GString*)(node->data)->str() it should print out the actual error. With that I'll know what to delete to clean up the error. I hope you made a backup before running those delete queries. BTW, while you don't need to build you shouldn't get version conflicts. Did you run sudo apt-get build-dep gnucash like the FAQ says?
Here is the output you asked for: 810 dialog-sx-since-last-run.c: No such file or directory. (gdb) p (GString*)(node->data)->str() Attempt to dereference a generic pointer. I have regular mysql backups. I can also easily recreate those three scheduled transactions. Are there more entries I can delete go tet 2.6.12 running again before your fix propagates? Thanks. Jeff
Sorry, the second gdb command should be p ((GString*)(node->data))->str() Here's one that should get you in so that you can edit the transactions: UPDATE schedxactions SET enabled = '0'; That will turn them all off so the Since Last Run dialog won't do anything and there won't be any errors to free. Then you can delete them all in the UI and recreate the ones that you want, or try enabling them one at a time to find the bad one.
Hmm, I don't think this is what you expect: 810 dialog-sx-since-last-run.c: No such file or directory. (gdb) p ((GString*)(node->data))->str() Program received signal SIGSEGV, Segmentation fault. 0x00000000009deee0 in ?? () The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on". Evaluation of the expression containing the function (at 0x0x9deee0) will be abandoned. When the function is done executing, GDB will silently stop.
This is what you were looking for: (gdb) p *((GString*)(node->data)) $2 = {str = 0x363bf70 "error -3 in SX [HSA Wind Quarterly] final gnc_numeric value, using 0 instead", len = 76, allocated_len = 128}
(In reply to jch from comment #28) > This is what you were looking for: > > (gdb) p *((GString*)(node->data)) > $2 = {str = 0x363bf70 "error -3 in SX [HSA Wind Quarterly] final gnc_numeric > value, using 0 instead", len = 76, allocated_len = 128} Yup, thanks for figuring out my mistake. Interesting, not at all the SX I suspected. Can you set a breakpoint: b gnc-sx-instance-model.c:1079 run it and do info locals I think it's going to tell me that it's trying to calculate 37500/100 - 0/1 and barfing because 100 != 1. If I'm right then we need a special case in the round-fixed routine to not raise that error when one of the operands is 0/1.
Breakpoint 1, split_apply_formulas (creation_data=0x7fffffffe1d0, creation_data=0x7fffffffe1d0, split=<optimized out>) at gnc-sx-instance-model.c:1079 1079 gnc-sx-instance-model.c: No such file or directory. (gdb) info locals err = <optimized out> credit_num = {num = 375, denom = 1} debit_num = {num = 8014, denom = 25} final = {num = -3, denom = 0} gncn_error = -3 sx = 0x2ea9070
8014/25 (320.56)? Where the heck did *that* come from? Have you restored from backup or is this with all of the SX formulas deleted? Does SELECT * FROM slots WHERE name LIKE "%numeric"; return anything?
No, I have not restored from backup, I'm not going to change anything until you have all the info. That query returns the attached numeric.txt. I suspect that is a former value for what is now 375.
Created attachment 328381 [details] %numeric
OK, that is indeed where the problem is. In order to avoid parsing issues with commas and dots depending on locale, beginning in 2.4.0 GC immediately stores a numeric when the formula has no variables. It appears that at some point you edited the the "HSA Wind Quarterly" SX and changed the amount and direction and somehow the numeric didn't get cleared on only one of the splits. I'll drag through the code and figure out why not. I have the information I need from your data, so go ahead and restore from backup. The safest query to make your database load in 2.6.12 is the UPDATE one from comment 26. I suggest that once you're in you delete and recreate "HSA Wind Quarterly" so that it's clean with no hidden numeric values to cause trouble. You'll have to enable the other two from the Overview tab of the SX editor.
*** Bug 769571 has been marked as a duplicate of this bug. ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=764871. Please update any external references or bookmarks.