GNOME Bugzilla – Bug 681907
Save operation is leaking seriously, eventually GnuCash uses 6.4 GB RAM
Last modified: 2018-06-29 23:10:06 UTC
GnuCash 2.4.10, r21973 compiled 2012-02-12, amd64 Ubuntu 12.04 amd64 Usage: 2 reports open 2 accounts open Using aqbanking HBCI every few days to get account statements and to balance accounts. top: After running for 2-3 months (I think): PID PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 24706 20 0 9281m 6.4g 22m S 1 40.6 9:36.50 gnucash After restarting GnuCash: 11797 20 0 2609m 355m 34m S 0 2.2 0:47.62 gnucash I have no idea why that is, and I can *not* help diagnose it, but I want to report that there is a *serious* problem with leaks.
After opening one more account (now 3), getting statements, and saving: 11797 20 0 2736m 483m 35m S 9 3.0 0:53.99 gnucash (That's 130 MB more) After saving: 11797 20 0 2857m 604m 35m S 0 3.8 0:55.49 gnucash (That's 120 MB more) After opening one more account (now 4), getting statements, and not saving: 11797 20 0 2861m 608m 35m S 0 3.8 0:56.57 gnucash After saving: 11797 20 0 2982m 729m 35m S 48 4.5 0:58.11 gnucash (That's again 120 MB more) **** So, it seems that the save operation (File|Save, gnucash file format) is leaking 120 MB each time it's used, and that memory is never reclaimed. **** Other memory is being reclaimed, I see the mem usage sometimes going down a few MB. I have the following save options: [x] Compress file Interval for saving automatically: 5 minutes Save log files: (o) Forever I just changed the latter to (o) Never, changed something, saved again. Now I have 855 MB, again 130 MB more. My gnucash file is 1 MB large on disk (presumably compressed) and contains about 10 years of statements, mostly private expenses, some business.
Does that still happen in 2.4.12?
I don't know, and I can't try. Please see comment 0: "I can *not* help diagnose it" You have the component and user action that's leaking, that should be enough to investigate.
Not enough data to reproduce as we don't have your account setups so not much that can be done I guess. Plus you run an old version...
Well, I can't and won't send you my gnucash file anyway, because it's highly sensitive. So you will have to find a way to reproduce it anyway, by creating a sufficiently large or realistic file. Or you just look in the XML save code whether you can find leaks in the code there.
Actually, any realistic file would probably reproduce it. Either it's leaking or not, just the amount will be different. For the unlikely case that the used features are relevant, I use: accounts, HBCI, saved reports, business features: just invoices. Rarely currency conversion (very few transactions between accounts with different currencies). But please first simply try to diagnose with a mem leaking tool with a normal real file of your choosing.
(In reply to comment #2) > Does that still happen in 2.4.12? I hit this bug in 2.4.13 as I had around 1500 log files, but it appears to have been fixed for 2.5 in changeset 22070: http://svn.gnucash.org/trac/changeset/22070 The leak is considerably worse when there are lots of log files, so as a temporary workaround, deleting older logs should reduce the symptoms. Given that this is a memory leak, is it possible for it to be back-ported to the 2.4 branch and for a new stable release to be made?
I have backported the change to the 2.4 branch. However I don't know if there will still be a release from that branch because we are really close to releasing 2.6. I'll bring that up with the other developers. What you can do is download the next weekly build of the 2.4 branch (which should appear next monday). With that build you can at least test if your memory leak is now fixed/reduced. The weekly builds appear here: http://code.gnucash.org/builds/win32/2.4/ Can you report back on the results please ?
Thanks for backporting the fix! Appreciated. I'm using GnuCash 2.4.10 on Ubuntu 12.04, installed from distro packages. I can build from source, but that's of course quite some effort.
There will be another 2.4 release in one of the following weeks. As that will most likely be the last 2.4.x release, the developers need some time to check what else is still desirable/possible to backport.
(In reply to comment #8) > I have backported the change to the 2.4 branch. However I don't know if there > will still be a release from that branch because we are really close to > releasing 2.6. I'll bring that up with the other developers. Thanks, it's great that there will be another 2.4 release. > Can you report back on the results please ? Sorry, I don't have a windows system to test, but I patched the Fedora package with that commit and got it built on koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=6237837 - that fixed this specific memory leak. I would consider the issue resolved…
(In reply to comment #11) > (In reply to comment #8) > > I have backported the change to the 2.4 branch. However I don't know if there > > will still be a release from that branch because we are really close to > > releasing 2.6. I'll bring that up with the other developers. > > Thanks, it's great that there will be another 2.4 release. > > > Can you report back on the results please ? > > Sorry, I don't have a windows system to test, but I patched the Fedora package > with that commit and got it built on koji: > http://koji.fedoraproject.org/koji/taskinfo?taskID=6237837 - that fixed this > specific memory leak. I would consider the issue resolved… Oh, I confused this bug with another one when thinking it was reported on Windows. Your test result on Fedora is equally fine. Thank you for your feedback.
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
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=681907. Please update any external references or bookmarks.