GNOME Bugzilla – Bug 772454
Gnucash crashes when opening new file
Last modified: 2018-03-13 12:37:17 UTC
Created attachment 336988 [details] Crash report from Mac OS X Sierra When switching from one file to another with file->open Gnucash crashes often, but not always, with a SIGSEGV. You can find the crash report in the attached file. This happened with any 2.6 release and probably even on 2.4
This is MacOS Sierra. I won't be able to test this until I return home in two weeks.
Created attachment 336993 [details] Crash with Mac OS X El Captain
Comment on attachment 336993 [details] Crash with Mac OS X El Captain This happened on El Captain too
That I can test locally. On the other hand I switch files pretty routinely and haven't ever had a crash. Is it perhaps a particular file of yours that's causing the problem?
I have about 10 files I am rotating. And it is happening about 80% of the time. I did not recognise any particular pattern. And it is definitely happening with multiple files. And not always with the same. I did the following experiment: 1 Created new file a with two accounts 2 Opened one of my files (L) --> crash 3 Created another new file b 4 Opened a --> fine 5 Opened b --> fine 6 Opened file L --> fine 7 Opened a --> fine 8 Opened existing file R --> crash Interestingly after the first crash R and L do not crash on reopening any more. I checked more of my files right now. Same here. First open --> crash. After that fine. Maybe some session specific state which is corrupt?
Getting nearer: The files are stored in a Veracrypt/Truecrypt container. After dismounting and remounting the container also the new files crash on changing files.
Hhm. Now not reproducible any more. After the next mount cycle files were fine.But only the ones I opened in the last cycle.
Hmm. The crash is happening while GnuCash is trying to restore the stored state, which would be in ~/Library/Application Support/Gnucash. Maybe there's some disconnect between the state stored there and what you have in your TrueCrypt volume? FWIW I use an Apple encrypted dmg (created with Disk Utilities) for my accounting files and have never had a problem. I don't include the state files in the .dmg.
Created attachment 337212 [details] Crash while closing old file Hi John, I am still trying to nail down the problem. While it still happens often I cannot find a pattern to reproduce it. But I have a new case: So far it normally failed while opening the new file and leaving the lock for that. This time it apparently crashed while closing the old because it left the lock for that.
I think it's still crashing while opening the new file, this time it just did it before it had established the session and closed the old file. The actual crash is in the gio/kqueue file monitoring code and seems to be because the file monitoring function is getting a pointer to freed memory for a filename. GnuCash doesn't use file monitoring so I'm at a bit of a loss as to how the monitoring event is getting on the queue. It doesn't seem likely to me that TrueCrypt is doing it; it uses wx and shouldn't know anything about the Gtk event loop. Try moving your files out of the TrueCrypt volume (you can always File>Save As from GnuCash if TrueCrypt makes that hard) and run for a few days that way. If it still crashes then we'll know if TrueCrypt is the problem.
Sorry, we'll know that TrueCrypt *ins't* the problem.
I did test for a while with an Apple encrypted image and the problem did not occur during these weeks. Today moved back to VeraCrypt and yes, it instantaneously happened again. So it really seems to by VeraCrypt/TrueCrypt
Sorry for the delay. I dug into it a wee bit this afternoon. The actual crash is at https://git.gnome.org/browse/glib/tree/gio/glocalfilemonitor.c?h=glib-2-48#n328, called from line 344: g_assert (!child || is_basename (child)); in g_file_monitor_source_handle_event, in turn called from https://git.gnome.org/browse/glib/tree/gio/kqueue/kqueue-helper.c?h=glib-2-48#n336: g_file_monitor_source_handle_event (source, mask, NULL, NULL, NULL, g_get_monotonic_time ()); It's a bit strange, it should be crashing because of the assert (!child) rather than segfaulting in is_basename(), but the underlying cause is pretty obvious. The monitor is being set by the gtk_file_chooser, which we *do* use in GnuCash. I'll see if we can disable that in the next release, but the actual crash belongs to glib so I'm reassigning the bug to them.
Interestingly I just got this crash while testing for bug 773808, using an encrypted dmg.
Hmm, looking at this again, I got the wrong call to g_file_monitor_source_handle_event; the problem isn't that it's being called with NULLs for child and rename_to, it's that it's being called in one of the callbacks (either handle_created or handle_deleted) and a bogus child--the offending address isn't NULL. It looks like the path in question is held in a heap-allocated structure called a dep_list. It's probably getting freed and not NULLed somewhere. Debugging that isn't fun.
Does running GnuCash under valgrind (with its memcheck tool) help to pinpoint the cause of the heap corruption?
Valgrind doesn't work very well on MacOS, but fortunately Apple's malloc library includes its own debugging tools. I haven't made this bug enough of a priority to use them.
(In reply to John Ralls from comment #17) > Valgrind doesn't work very well on MacOS, but fortunately Apple's malloc > library includes its own debugging tools. I haven't made this bug enough of > a priority to use them. OK, thanks. Setting as NEEDINFO until you do get time to take a look.
Bug #739424 just landed a significant rewrite of the kqueue backend, which changes how the refcounting works on sources. It likely fixes the bug here, although since this was never completely debugged, I can’t be sure. I’m going to close this as OBSOLETE, though; if you can reproduce the problem with GLib master, please reopen this bug report. Thanks!