GNOME Bugzilla – Bug 431324
Memory leaks with file loads?
Last modified: 2018-06-29 21:32:37 UTC
Please describe the problem: Gnucash appears not to be freeing memory from the previous file if you load a new file. If you start gnucash and it loads a data file, then you select File->Open and open another data file, it grabs memory for the new data file, but does not free the memory used for the first data file. This is especially noticable if you use large data files :-). Steps to reproduce: 1. Start gnucash and load large data file 2. Check Gnucash's memory usage 3. Go File -> Open and open another large data file. 4. Check memory usage again. Notice that its much larger. Actual results: Expected results: Does this happen every time? Reproducable. 4 out of 4 tests of this so far. Other information: Entered as a bug against the XML backend because I cannot test it to see if its actually at a higher level. Entered as a critical bug because Bugzilla suggests that a bug which makes the application leak large amounts of memory is a critical bug.
Have you actually verified the memory usage by valgrind/memcheck? Or did you "only" look at the memory usage in "top" or similar? Before we even start to work on this issue, I'd like to have memory leaks verified by valgrind. In my experience, memory things often behave differently than one would think, and only an actual memory checker will tell you the truth.
See http://lists.gnucash.org/pipermail/gnucash-devel/2007-May/020551.html ; valgrind was started with the following options (among others) --tool=memcheck --leak-check=full --trace-children=yes --error-limit=no --log-file=mycheck ; However, currently the only reported leak in there is in glib's g_get_filename_charsets() (this is glib2-2.12.4), but there does not seem to be a significant leak in gnucash itself. Perhaps the memcheck option --show-reachable=yes might show something interesting.
While working on another issue, I noticed that Account objects didn't seem to get cleaned up when a book was closed. In particular, xaccFreeAccount was not being called except for one SX-related account. I suspected this might result in memory leakage, so I hacked up src\backend\file\test\test-load-xml2.c to load each file 10,000 times rather than just once. When I ran the associated test executable, its memory usage (both Mem Usage and VM Size as seen with Windows Task Manager) did in fact steadily climb with each iteration of the loop. As I am currently stuck on Windows and do not have access to tools like valgrind, I have not done any more to try to confirm that Account objects are being leaked or to see if anything else is being leaked. However, it definitely does appear that memory is being left allocated when a book is closed.
Daniel, I think you are absolutely right. I noticed the same while wondering why the test-lots test eats up that much memory and even after adding a missing qof_session_destroy() the test did not seem to free the memory allocated for the random engine objects. CC'ing warlord as overlord :-) So, who is supposed to free that data by design? I would really like to see this one fixed.
QOF is supposed to free the data when you end a session.
This is still occurring in 2.4.99 r20741.
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=431324. Please continue processing the bug there and please update any external references or bookmarks.