GNOME Bugzilla – Bug 730152
Memory leak when listening to object:text-changed events
Last modified: 2016-03-31 16:46:50 UTC
Created attachment 276567 [details] build with: gcc leaktest1.c -o leaktest1 $(pkg-config --cflags --libs gobject-2.0 glib-2.0 atspi-2) Hi, have a look at the attached C-sample. It seems it is enough to register an event listener for object:text-changed events to leak large amounts of memory. Steps to reproduce: 1) build and run leaktest1.c (or launch Orca or Onboard) 2) monitor memory usage (logmem leaktest1 if you like, attached below) 3) start synaptic package manager -> heap grows from <1MB to 135MB 4) "Manage news group subscriptions" for "news.mixmin.net" account in Thunderbird and slowly type 'news' as search filter -> heap grows from 135MB to 211MB We noticed this first with Onboard's memory usage growing into the hundreds of MB to GB, see original bug report here https://bugs.launchpad.net/bugs/1317436 however Orca seems to be affected as well and it happens across distributions, at least Mageia 5 (Cauldron) and Ubuntu 14.04. at-spi2-core 2.10.2.is.2.10.1-0ubuntu1 synaptic 0.81.1 thunderbird 1:24.5.0+build1-0ubuntu0.14.04.1
Created attachment 276568 [details] memory logger, logmem leaktest1|orca|onboard
Created attachment 276569 [details] valgrind log valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --log-file=valgrind.log ./leaktest1
Any news on this? This is a significant memory leak that leads to lockups on at least one of the systems in the original bug report.
I apologize--I started looking for memory leaks a while ago and fixed several for 3.14, but I never verified this bug. I've just tested thunderbird with 3.20.0. When I select "manage newsgroup subscriptions" and type "news", memory usage goes up, and it does not go back down when thunderbird exits, but, if I repeat the above steps, then I see no further increases. So, while it appears that memory is being allocated without being released, I am not seeing a leak. Libdbus has its own wrapper around malloc, and I suspect that it is allocating enough memory to handle a large queue of messages but not freeing it. Anyway, several leaks in AT-SPI have been fixed, and I think that I can close this bug. Please re-open if you still see a leak.