GNOME Bugzilla – Bug 715041
Crash opening a file when a file is already open.
Last modified: 2018-06-29 23:21:46 UTC
Created attachment 261273 [details] Crash report I get frequent crashes when opening a file when GnuCash already has a file open. A typical stack trace leading to the crash is attached. The crash happens in WebKit the first time the progress bar is updated while loading the new file when gnc_window_show_progress attempts to process pending events to get the progress bar updated. This seems to imply that there is an event pending for a WebKit object after it has been released. I suspect that even when the crash doesn't occur some free memory is being clobbered.
It isn't the heap getting clobbered, it's the stack, see frame 10. Does either file have an open report tab when this happens?
The immediate cause of the crash is the use of an invalid pointer that points to a bad address. I'm quite willing to believe that prior to this other pointers were used that, while pointing to valid addresses, were wrong and the stack may have gotten clobbered by that. I don't know why this happened, but my best guess is still an event directed to an object which had been at least partly freed. Both files had reports open. Presumably it's the file being closed that is the problem since GnuCash hasn't gotten far enough to read anything from the file being opened. You can't tell from this crash report, but I've had this happen in the debugger and it's the very first call to gnc_window_show_progress that is crashing, before any of the file has been read. This is also, I think, the first time events are processed after the file is closed. The file being closed has 8 reports open. I tried closing various of them to see if any particular report caused it. When I got down to only 2 open, it stopped happening, but it didn't seem to matter which 2 were open. Opening 4 was enough to make it happen. Since it's not 100% repeatable this test may not mean all that much, except to probably show that it's not a particular report that is the issue.
It turns out that we're a victim of bug 119003 in WebKit (https://bugs.webkit.org/show_bug.cgi?id=119003). It sometimes sets a timer interrupt to remind itself to adjust scroll bars on a view and if the timer is pending when the object is deleted it sometimes forgets to cancel it. Later when the timer fires it tries to use an object which has been freed. This bug was fixed in WebKit version r153052 which appears to have been part of release 2.1.4. I'm using the WebKit installed by MacPorts which is version 2.0.4. I've got a simple two line fix that circumvents this problem which I'll check in later. It flushes all events after closing a page which might trigger WebKit to set this timer interrupt. That way it won't be still pending when it later closes the WebKit page. If you think this is too ugly and we should instead require a later version of WebKit, we can revert this change.
I checked in the change to circumvent the problem in r23440
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=715041. Please update any external references or bookmarks.