GNOME Bugzilla – Bug 734833
Gnucash crashes regularly
Last modified: 2018-06-29 23:32:55 UTC
Created attachment 283436 [details] trace file before the crash I am using gnucash 2.6.3 with many reports open all the time (around 40). Recently (mainly after updating to 2.6.3) gnucash crashes after viewing 'x' amount of reports. Its normally around 8-10 reports. It gives me a gnucash has stopped responding error. I have to do end program and reopen the gnucash. Then I get window with "That database may be in use by another user" , and I click Open Anyway. I am using Win8 pro with 64 gb ram, intel i7 3.4 Ghz. If you are asking why I have so many reports (~40) open all the time, my answer is that it is very efficient to keep them open and review them daily (instead of generating it every time). attached is the trace file from temp directory.
GnuCash has its own product; moving
Unfortunately a trace file isn't going to help find what's probably a memory error. We need a stack trace to see what's failing and where. The instructions are at http://wiki.gnucash.org/wiki/Stack_Trace, but they're difficult to do on Windows and beyond the abilities of most users. You can at least confirm my suspicion that the problem is resource leakage by opening task manager and observing the memory use of Gnucash in the "processes" tab; if I'm right it will increase as you open new reports and switch between them until some large value is reached, at which point GnuCash will crash.
I monitored the Task Manager as you requested. What I noticed were: 500 MB when opened for first time. 5 clicks on different reports brings memory usage to 730 MB every new report clicked adds quickly to 1 GB Gnucash crashes (not responding) at 1.074 GB I clicked on your link to get Stack Trace but did not find the instructions there. I can try to get if needed. I really want to help fix this bug.
Mmmph. I restored the Windows instructions at http://wiki.gnucash.org/wiki/Stack_Trace#Windows , but gdb isn't that useful for leak detection. I'll try replicating it when I can make some time.
Had to run Gnucash in full-screen mode and make the graphs all 1800x850 to get it to crash, which it did on the 10th report at 1419M; this on a Win7 VM with 4G of available memory. This was after running it up to 10 open reports, closing them, and opening 10 more. I was able to examine the call stack a bit in Visual Studio, and it was a segfault in libgdk after many libguile calls. It wouldn't crash for me when running under gdb, only to hang, and there's no way in MinGW's gdb to halt execution and look at the stack when that happens. Unfortunately it looks like the problem has more to do with Guile than with Gnucash. I speculate that the problem is that a malloc failed and the resulting NULL was passed, without having been checked, in to Gdk, which crashed. Since crashing is the normal response to memory exhaustion that's not as unreasonable behavior as it seems. It's possible that upgrading Guile to 2.0 will fix this, but last I heard there are problems building Guile 2.0 on Windows. I did notice that creating and deleting reports doesn't reduce the amount of memory used all the way back to where it was before the report was opened, so there are definite memory leaks in Gnucash. Where they are and whether its Windows-only I haven't yet determined. The best I can offer in the meantime is the suggestion that you make the graphs smaller; at the default sizes they use half as much memory, such that with 12 reports open GnuCash was using only 330M.
I am using gnucash-2.6.4 under Linux and I experience regular crashes also. It crashes when I press OK on transfer dialog. Here is a backtrace:
+ Trace 234296
(In reply to comment #6) > I am using gnucash-2.6.4 under Linux and I experience regular crashes also. It > crashes when I press OK on transfer dialog. > > Here is a backtrace: > > That's a different crash entirely. Please open a new bug report. The stack trace suggests a corrupted commodity or currency, so please note on your new report what commodities or currencies are involved in the transfer when it crashes.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=734833. Please continue processing the bug there and please update any external references or bookmarks.