GNOME Bugzilla – Bug 649142
Application Exit while Save in process Cancels save and loses data
Last modified: 2018-06-29 22:57:28 UTC
I have found out (the hard way) that if Gnucash is in the process of saving the file, and you then attempt to close the application, Gnucash gets confused, and will not save your data. I am using 2.4.5 on OS X 10.6.7. To reproduce: 1) Choose File->Save 2) While Gnucash is saving, Apple-Q to quit 3) The "Your file has changes, save?" dialog appears. Clicking Save does nothing; clicking Close anyway "works"--but the changes are lost, despite the in-process save. I do not know whether this happens on other OSes. I have marked this a Major bug since it results in lost data.
By the way, this can happen if you're tabbing around applications; the tab key and the q key are neighbors...
Yup, Apple handles quitting specially, and it's outside of GTK. I can add a "save in progress" mutex and check it in the close code. On the other hand, telling it to "close anyway" while the save was still going on was not exactly a smart thing to do.
John-- The problem here is that once the dialog is presented, the save apparently stops, and the Save button does not work. Clicking Save does nothing. So one's only option is "Close Anyway". Once you have hit Apple Q (as I noted in my second comment, this was a result of fat fingers trying to Apple-Tab to another program), your changes are hosed, and there's no way around it. David
David, I've reworked the shutdown code to fix this; it's in 2.4.7 It works correctly on my machines, but a user reported a crash on the dev list this morning. Would you test it, please?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
Reopening because of a new report on the mailing list. Process: Gnucash-bin [17816] Path: /Applications/Gnucash.app/Contents/MacOS/Gnucash-bin Identifier: org.gnucash.Gnucash Version: 2.4.7 (2.4.7) Code Type: X86 (Native) Parent Process: launchd [160] Date/Time: 2011-09-19 22:38:47.757 +0200 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Interval Since Last Report: 562064 sec Crashes Since Last Report: 1 Per-App Interval Since Last Report: 743423 sec Per-App Crashes Since Last Report: 1 Anonymous UUID: 3149E1CA-3601-4AA6-A982-5EE130D26557 Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: objc[17816]: FREED(id): message timeIntervalSinceNow sent to freed object=0x2e9c0c0 Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x9a0414fd _objc_error + 116 1 libobjc.A.dylib 0x9a041533 __objc_error + 52 2 libobjc.A.dylib 0x9a03f83a _freedHandler + 58 3 com.apple.AppKit 0x9a1a4dbd _DPSNextEvent + 2935 4 com.apple.AppKit 0x9a1a3dd6 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156 5 libgdk-quartz-2.0.0.dylib 0x024266a7 poll_func + 135 6 libglib-2.0.0.dylib 0x02931db3 g_main_context_iterate + 1027 7 libglib-2.0.0.dylib 0x02932197 g_main_loop_run + 471 8 libgtk-quartz-2.0.0.dylib 0x020b7c21 gtk_main + 177 9 libgncmod-gnome-utils.dylib 0x0021e2c1 gnc_ui_start_event_loop + 81 10 Gnucash-bin 0x00019b1e inner_main + 686 11 libguile.17.dylib 0x018f15c1 invoke_main_func + 65 12 libguile.17.dylib 0x018c0f12 c_body + 18 13 libguile.17.dylib 0x01939a85 scm_c_catch + 533 14 libguile.17.dylib 0x018c137a scm_i_with_continuation_barrier + 154 15 libguile.17.dylib 0x018c143e scm_c_with_continuation_barrier + 78 16 libguile.17.dylib 0x0193848b scm_i_with_guile_and_parent + 43 17 libguile.17.dylib 0x01938569 scm_with_guile + 41 18 libguile.17.dylib 0x018f155a scm_boot_guile + 58 19 Gnucash-bin 0x00019192 main + 2178 20 Gnucash-bin 0x000188d6 start + 54 Thread 1: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x904c2382 kevent + 10 1 libSystem.B.dylib 0x904c2a9c _dispatch_mgr_invoke + 215 2 libSystem.B.dylib 0x904c1f59 _dispatch_queue_invoke + 163 3 libSystem.B.dylib 0x904c1cfe _dispatch_worker_thread2 + 240 4 libSystem.B.dylib 0x904c1781 _pthread_wqthread + 390 5 libSystem.B.dylib 0x904c15c6 start_wqthread + 30 Thread 2: 0 libSystem.B.dylib 0x904a6e5e read$UNIX2003 + 10 1 libglib-2.0.0.dylib 0x0292f2ce child_watch_helper_thread + 78 2 libglib-2.0.0.dylib 0x0295832a g_thread_create_proxy + 58 3 libSystem.B.dylib 0x904c9259 _pthread_start + 345 4 libSystem.B.dylib 0x904c90de thread_start + 34 Thread 3: 0 libSystem.B.dylib 0x904c9aa2 __semwait_signal + 10 1 libSystem.B.dylib 0x904c975e _pthread_cond_wait + 1191 2 libSystem.B.dylib 0x904cb3f8 pthread_cond_wait$UNIX2003 + 73 3 libgdk-quartz-2.0.0.dylib 0x02426265 select_thread_func + 357 4 libSystem.B.dylib 0x904c9259 _pthread_start + 345 5 libSystem.B.dylib 0x904c90de thread_start + 34 Thread 4: 0 libSystem.B.dylib 0x904c1412 __workq_kernreturn + 10 1 libSystem.B.dylib 0x904c19a8 _pthread_wqthread + 941 2 libSystem.B.dylib 0x904c15c6 start_wqthread + 30 Thread 5: 0 libSystem.B.dylib 0x904c1412 __workq_kernreturn + 10 1 libSystem.B.dylib 0x904c19a8 _pthread_wqthread + 941 2 libSystem.B.dylib 0x904c15c6 start_wqthread + 30 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x2059a240 ebx: 0x9a04149d ecx: 0x2059a240 edx: 0x2059a290 edi: 0x1f8dc410 esi: 0x9a04b7b7 ebp: 0xbfffdd38 esp: 0xbfffdcf0 ss: 0x00000023 efl: 0x00010282 eip: 0x9a0414fd cs: 0x0000001b ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f cr2: 0x1fc26000
Actually, John, the description in the list (and I can confirm the behavior described there) is decidedly NOT the same as I described before. FWIW, the problem I described is not happening any more; this problem looks different. I cannot confirm this right now, but I think that for me, the data is being saved even though there is nothing on screen to indicate this. I will also note that when I reproduce the other poster's problem, the next start up does not raise problems with the lockfile, suggesting that it is being cleared as well.
How should this bug continue ? Dave claims the original problem has been solved, but another user posted a similar problem. So, should the similar problem be cloned into a new bug report and this one be closed, or do you prefer to keep this one open ? In any case, I have reset the target milestone for now, because that one has passed. When you decide to close this bug as fixed anyway, you can choose to reset the target milestone to 2.4.7 again, as that's where it was fixed.
I think we can close this, because I can't reproduce it in 2.4.8. If it comes up again I'll open a new bug.
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=649142. Please update any external references or bookmarks.