GNOME Bugzilla – Bug 643363
transaction edit made PostgreSQL data file un-openable
Last modified: 2018-06-29 22:54:12 UTC
During the course of attempting to edit a stock transaction which had been imported from Quicken 2008 to correctly represent a re-invested dividend, GnuCash crashed. Attempting to restart GnuCash , it crashed again. On the following attempt, it was unable to obtain the lock for postgres://[user]:[pw]@[redacted]. Clicking on Open Anyway causes Gnucash to crash. I can open the data file with pgAdmin III and peruse it at will. I used the Vacuum function to clean up abandoned data, but that did not fix the file to allow GnuCash to open it without crashing. I think that the problem was caused specifically by attempting to use the action called income in the stock transaction, and prematurely hitting the enter key before selecting a valid account for that action. I believe that both a work-around is needed to recover this file, and a bug fix to prevent it's recurrence. In addition, a documented procedure to periodically back up and recover postgresQL databases would be very much appreciated. David
Please attach a copy of your gnucash.trace file, and if you can make one, a backtrace from the crash (http://wiki.gnucash.org/wiki/Stack_Trace). The work-around is to roll back your database. You'll have to learn how to be a Postgresql DBA somewhere else, no one here is. Until you gain those skills, you should use one of the file-based backends (XML or Sqlite3).
Created attachment 182005 [details] Trace File possibly from initial crash session There were other crashes as I was learning. those did not damage the database irrecoverably.
Created attachment 182006 [details] Trace from a post mortem crash This is from one of the crashes when attempting to re-open the database.
My follow-up comments that were supposed to accompany the the attachments got lost. I will try to recreate them. You saw right through my fake glasses and mustache disguise. I actually know only enough to be dangerous, and again I have proved it. Whatever help you can give me will be greatly appreciated. There are several other trace files, so if I attached the wrong one(s), I will need some help identifying the correct one. I will now try to do the backtrace. David
If you edit the SQL database directly (with pgAdmin or whatever other external software), your file gets destroyed for usage within gnucash. Please don't use the postgreSQL storage medium; instead, only use XML or sqlite3. If you want to have the postgreSQL backend fixed, you would have to come up with a (small) example file (i.e. postgreSQL database) that shows your problem: It crashes upon opening. Then attach this example file here and we'll see what we can do. But I'd say just leave the postgreSQL storage alone and only use XML or sqlite. Thanks.
(In reply to comment #5) > If you edit the SQL database directly (with pgAdmin or whatever other external > software), your file gets destroyed for usage within gnucash. Please don't use > the postgreSQL storage medium; instead, only use XML or sqlite3. That actually applies to any backend. We do not support, and discourage in the strongest terms possible, writing to Gnucash storage except through the Gnucash API. But I do want to know where we've got an unprotected pointer and make it barf gracefully instead of crashing, so if you can get that backtrace it would be great.
I got stuck on the backtrace because I could not follow the directions exactly as written. I got gdb running, but I didn't succeed in starting gnucash from within the program. While attempting to: Starting GnuCash under gdb ... 1. run "gnucash-env gdb gnucash-bin" 2. at the gdb prompt, type: "run". Also add your parameters here, like "run --nofile" 3. Provoke the crash; type "backtrace" or shorthand "bt" at the gdb prompt to obtain the backtrace ("bt full" might provide additional info about local variables). Windows did not recognize gnucash-env as a program so I started gdb directly in a command window after switching to C:\MinGW\bin directory for gdb. Then step 2 failed to start gnucash. I do not know enough about gdb to issue a valid start command. My desktop Gnucash shortcut points to "C:\Program Files\gnucash\bin\gnucash.exe" Can you help me with this? Thank you.
Since 2.4 the way to start gnucash from gdb has slightly changed. And you tried to follow the linux instructions of obtaining a stack trace. That won't work under Windows. I noticed by the way that the Windows instructions [1] weren't up to date yet, so I have adapted them. Can you try to follow those [1] ? [1] http://wiki.gnucash.org/wiki/Windows#Debugging_with_gdb
Created attachment 182149 [details] GDB Backtrace The actual BT is about 1/3 of the way through this file. I started the backtrace after gnucash crashed while trying to open the PostgreSQL database referenced earlier in this bug report.
When I did the following: * GnuCash 2.4.0 and more recent * Open a Windows command prompt and type: set PATH=C:\Program Files\gdb\bin;%PATH% gdb C:\Program Files\gnucash\bin\gnucash Be careful to use the actual paths in which you have installed gdb and gnucash respectively. * For all versions: this will open a gdb prompt * Type run at the gdb prompt. * Then provoke the crash and type backtrace or shorthand bt at the gdb prompt to obtain the backtrace, as explained on Stack Trace as well. first, I found that I needed to use quotes around "C:\Program Files\gnucash\bin\gnucash" to start gdb with the program. Then I tried unsuccessfully to echo the output to a file, so a copy of the console output is attached. The backtrace starts about a third of the way down.
If it makes any difference, I installed gnucash version 2.4.3 before running this backtrace.
Very strange. You said that you'd damaged the file while working on a stock transaction, but it's crashing while trying to load a budget record.
I had been attempting to create a budget shortly before. If I recall, I set that aside because I did not have good history to base the budget on. I have had a few instances when the program seemed to jump to a completely different account tab or do other strange things if my fingers slipped as I was typing. However, I very rarely hit ctrl, shift, or Alt accidentally. It is possible that while I was trying to edit a stock transaction, the program may have wandered off to the budget tab. Does that make any sense? I am so new to this program that I only know a few of the most common shortcuts. My computer is heavily loaded and it sometimes has several second lapses when it appears to hang and/or background operations lag considerably. There is a Western Digital external hard drive that takes up most of the CPU's free time. The other possibility is that the PostgreSQL vacuum command made some change that affected a budget record or a link. I did execute that command successfully and I am fairly certain that it did remove several presumably abandoned records. The cause of this database corruption may remain a mystery, but I hope that you can make the program 'barf' instead of crashing. Actually, I prefer to use the phrase 'fail gracefully'
(In reply to comment #10) > When I did the following: > > * GnuCash 2.4.0 and more recent > > * Open a Windows command prompt and type: > > set PATH=C:\Program Files\gdb\bin;%PATH% > gdb C:\Program Files\gnucash\bin\gnucash > > Be careful to use the actual paths in which you have installed gdb and > gnucash respectively. > > * For all versions: this will open a gdb prompt > * Type run at the gdb prompt. > * Then provoke the crash and type backtrace or shorthand bt at the gdb > prompt to obtain the backtrace, as explained on Stack Trace as well. > > first, I found that I needed to use quotes around "C:\Program > Files\gnucash\bin\gnucash" to start gdb with the program. Yes, you are right. I have adapted the wiki page. Thanks !
David, can you verify the version (the svn revision from the About window would be ideal)? The line number and function don't match up for 2.4.0.
See comment 11: David used GnuCash 2.4.3
I'm marking this as a duplicate of a more recently reported bug because that bug explicitly describes the cause: The SQL backend doesn't like having a budget that refers to a deleted account. *** This bug has been marked as a duplicate of bug 674283 ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=643363. Please update any external references or bookmarks.