GNOME Bugzilla – Bug 443941
Crash while opening locked file after earlier crash
Last modified: 2018-06-29 21:38:25 UTC
I receive the Windows error ("gnucash-bin.exe has encountered a problem and needs to close. We are sorry for the inconvenience.") in the following circumstances: 1. I saved an account file I had been editing with GnuCash 2.1.1 2. I left GnuCash open with the account file open 3. I placed my machine (2 GHz Celeron 496 MB Toshiba Satellite running Windows XP Pro SP 2) in sleep mode 4. I resumed my session 5. GnuCash 2.1.1 ceased responding 6. I terminated GnuCash 2.1.1 --- 7. I restart GnuCash 2.1.1 8. I try to open my account file 9. I receive the message that the file was locked 10. I click the "Continue" option 11. The loading bar in the lower right corner reaches the far right edge 12. Windows announced the error quoted above * Repeating steps 7-10 with GnuCash 2.1.2 and GnuCash 2.1.3 yields results 11 and 12. * I have tried deleting the ior file found in $user/Local Settings/Temp/gnucash-&user/lock/, but without effect -- GnuCash does, however, create a new ior file after I have deleted the old one. [* In the event it is significant, I note that while I was running GnuCash 2.1.1, I switched from an "extended desktop" display to "laptop" only (this machine has the Intel 82852/82855 chip-set).] I assume the foregoing behavior is undesirable, even if the account file is somehow corrupt beyond GnuCash's ability to repair. I am wondering whether there is any way (perhaps through hand-editing) to recover the data in the file?
A few suggestions: * make a backup of your data file * determine what is corrupt, your data file, state file or gconf state (~ is C:\Documents and Settings\$user) - kill gconfd-2.exe, move ~\.gconf and ~\.gconfd away to a safe location, retry. on success, append zipped .gconf directory - move ~\.gnucash away to a safe location, retry. on success, append zipped state file, which is ~\.gnucash\books\$yourbook (on multiple, check guid against that in your data file (uncompressed)) - uncompress your data file (get 7zip, rename file to $file.gz, gunzip), look whether it looks sane, strip parts away and retry... or append, but I guess it contains sensitive data * check ~\Local Settings\Temp\gnucash.trace.* files
(In reply to comment #1) > A few suggestions: > * make a backup of your data file > * determine what is corrupt, your data file, state file or gconf state (~ is > C:\Documents and Settings\$user) > - kill gconfd-2.exe, move ~\.gconf and ~\.gconfd away to a safe location, > retry. on success, append zipped .gconf directory That did not succeed. > - move ~\.gnucash away to a safe location, retry. on success, append zipped > state file, which is ~\.gnucash\books\$yourbook (on multiple, check guid > against that in your data file (uncompressed)) That did not succeed. > - uncompress your data file (get 7zip, rename file to $file.gz, gunzip), look > whether it looks sane, strip parts away and retry... or append, but I guess it > contains sensitive data Examination of that file (390KB) revealed an apparently well-formed XML file. > * check ~\Local Settings\Temp\gnucash.trace.* files Each attempt in this series generated an identical trace file, containing the following: * WARN <qof.engine> [guid_init()] only got 2214 bytes. The identifiers might not be very random. * WARN <gnc.engine> failed to load gnc-backend-postgres from C:\Program Files\gnucash\lib\gnucash * WARN <gnc.backend.file> Invalid timestamp in data file. Look for a 'trn:date-posted' entry with a date of 1969-12-31 or 1970-01-01. * CRIT <gnc.engine.recurrence> recurrenceToString: assertion `g_date_valid(&r->start)' failed * CRIT <GLib> g_string_append: assertion `val != NULL' failed * CRIT <gnc.engine.recurrence> recurrenceNextInstance: assertion `g_date_valid(&r->start)' failed * CRIT <GLib> g_date_strftime: assertion `g_date_valid (d)' failed * CRIT <gnc.engine.recurrence> recurrenceToString: assertion `g_date_valid(&r->start)' failed There is also one 4MB trace file, which I think was generated in the crash that ate my account file. I also have trace files from my several attempts to recover with 2.1.1 and 2.1.2; they are only slightly different from the example above. I am willing (if necessary) to share with a limited number of trust-worthy people the account file at issue, but I do not wish to post it on a public forum. Thanks for your help.
One more note: A search of the account file did turn up one date of 1970-01-01 in a 'trn:date-posted' entry. I changed the date to '2006-06-01', saved and gzipped it with 7zip, and tried opening the result with GnuCash 2.1.3, with like results. The trace file contains: * WARN <qof.engine> [guid_init()] only got 2209 bytes. The identifiers might not be very random. * WARN <gnc.engine> failed to load gnc-backend-postgres from C:\Program Files\gnucash\lib\gnucash * CRIT <gnc.engine.recurrence> recurrenceToString: assertion `g_date_valid(&r->start)' failed * CRIT <GLib> g_string_append: assertion `val != NULL' failed * CRIT <gnc.engine.recurrence> recurrenceNextInstance: assertion `g_date_valid(&r->start)' failed * CRIT <GLib> g_date_strftime: assertion `g_date_valid (d)' failed * CRIT <gnc.engine.recurrence> recurrenceToString: assertion `g_date_valid(&r->start)' failed
Re comment 2, you can contact me by email (see also http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB9C00CD7) Did you try the "strip off parts and retry" thing? You could start with recurrences.
Thanks! I am working on it---expect a repository fix and a workaround in the following days.
Workaround: Append <fs:once> <fs:date> <gdate>2007-05-27</gdate> </fs:date> </fs:once> after each <fs:ui_type>once</fs:ui_type> that lacks this information. Replace 2007-05-27 by the actual date, of course.
The crash has been fixed in r16214. Jsled, any news regarding <gnc:schedxaction version="1.0.0"> <sx:id type="guid">97a1237b611df2d124366c35e9f5dc9f</sx:id> <sx:name>Some name</sx:name> <sx:autoCreate>n</sx:autoCreate> <sx:autoCreateNotify>n</sx:autoCreateNotify> <sx:advanceCreateDays>0</sx:advanceCreateDays> <sx:advanceRemindDays>0</sx:advanceRemindDays> <sx:instanceCount>4</sx:instanceCount> <sx:start> <gdate>2006-07-01</gdate> </sx:start> <sx:last> <gdate>2006-10-01</gdate> </sx:last> <sx:end> <gdate>2006-10-01</gdate> </sx:end> <sx:templ-acct type="guid">a66efe3144a3535fc6ac12955c8d7c75</sx:templ-acct> <sx:freqspec> <gnc:freqspec version="1.0.0"> <fs:id type="guid">a347b64a8c5049f33528e98ad8c85846</fs:id> <fs:ui_type>once</fs:ui_type> </gnc:freqspec> </sx:freqspec> </gnc:schedxaction>
I'd been hesitating on removing the freqspec emission code ... just in case ... but since the code no longer takes care to maintain the freqspec objects, there's really no point. As per this case, it just causes more problems than it solves. I've removed the FreqSpec generation code in r16233 / 2.1.5; this problem shouldn't re-occur.
(updating target)
*** Bug 438520 has been marked as a duplicate of this bug. ***
*** Bug 453004 has been marked as a duplicate of this bug. ***
I think comment 6 might be OK to make GnuCash load the file, but it probably does not help you recover your scheduled transaction. As soon as GnuCash 2.1.5 is available as Windows package, I beg you to check that out and try the same you did to make GnuCash write this stuff. From a theoretical point of view, I believe jsled that the bug is fixed, but you never know :-D
I confirm taht this is fixed in 2.1.5, at least my problems related to bug 453004 (dupe of this one) were solved.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=443941. Please update any external references or bookmarks.