@smoser, The runaway process was indicator-mutli as it was the process consuming the most memory (5.7G) in one case.
FWIW, I've also run valgrind on indicator-multiload using: G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --track-origins=yes --log-file=valgrind.log /usr/bin/indicator-multiload
I'll attach this log if it helps somebody with debugging.
In https://bugs.launchpad.net/ubuntu/+source/indicator-multiload/+bug/956810/comments/7, @keturn mentions a patch that could have introduced a memory leak in libdbusmenu. This would be a good experiment to try and revert this patch and see if the memory leaks persist (or at least the egregious offenders).
@smoser,
The runaway process was indicator-mutli as it was the process consuming the most memory (5.7G) in one case.
FWIW, I've also run valgrind on indicator-multiload using: always- malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --track-origins=yes --log-file= valgrind. log /usr/bin/ indicator- multiload
G_SLICE=
I'll attach this log if it helps somebody with debugging.
In https:/ /bugs.launchpad .net/ubuntu/ +source/ indicator- multiload/ +bug/956810/ comments/ 7, @keturn mentions a patch that could have introduced a memory leak in libdbusmenu. This would be a good experiment to try and revert this patch and see if the memory leaks persist (or at least the egregious offenders).