After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 681907 - Save operation is leaking seriously, eventually GnuCash uses 6.4 GB RAM
Save operation is leaking seriously, eventually GnuCash uses 6.4 GB RAM
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Backend - XML
2.4.x
Other Linux
: Normal major
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
Depends on:
Blocks:
 
 
Reported: 2012-08-15 11:34 UTC by Ben Bucksch
Modified: 2018-06-29 23:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ben Bucksch 2012-08-15 11:34:48 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.
Comment 1 Ben Bucksch 2012-08-15 11:48:14 UTC
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.
Comment 2 André Klapper 2012-08-15 13:59:38 UTC
Does that still happen in 2.4.12?
Comment 3 Ben Bucksch 2012-08-15 14:03:18 UTC
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.
Comment 4 André Klapper 2012-08-15 14:14:56 UTC
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...
Comment 5 Ben Bucksch 2012-08-15 14:22:49 UTC
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.
Comment 6 Ben Bucksch 2012-08-15 14:29:07 UTC
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.
Comment 7 Kat 2013-11-23 00:48:19 UTC
(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?
Comment 8 Geert Janssens 2013-11-27 11:17:28 UTC
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 ?
Comment 9 Ben Bucksch 2013-11-27 15:43:58 UTC
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.
Comment 10 Geert Janssens 2013-11-28 16:05:06 UTC
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.
Comment 11 Kat 2013-11-28 18:59:46 UTC
(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…
Comment 12 Geert Janssens 2013-11-29 08:24:32 UTC
(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.
Comment 13 Geert Janssens 2013-12-10 17:39:47 UTC
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
Comment 14 John Ralls 2017-09-24 22:44:01 UTC
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
Comment 15 John Ralls 2018-06-29 23:10:06 UTC
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.