GNOME Bugzilla – Bug 168679
gail_widget_size_allocate_gtk leaks memory
Last modified: 2005-04-05 16:42:03 UTC
Please describe the problem: I was playing around with gnome-panel under valgrind and found: ==4975== 31024 bytes in 1108 blocks are definitely lost in loss record 11505 of 11517 ==4975== at 0x3414AF01: calloc (in /usr/lib/valgrind/vgpreload_addrcheck.so) ==4975== by 0x34BA9A55: IA__g_malloc0 (gmem.c:154) ==4975== by 0x34AE6CFF: ORBit_alloc_by_tc (allocators.c:367) ==4975== by 0x34AE281F: ORBit_small_alloc (orbit-small.c:44) ==4975== by 0x34E48E31: spi_init_any_rect (util.c:143) ==4975== by 0x34EBC028: spi_atk_bridge_signal_listener (bridge.c:984) ==4975== by 0x34B293F2: signal_emit_unlocked_R (gsignal.c:2451) ==4975== by 0x34B2A53D: IA__g_signal_emit_valist (gsignal.c:2244) ==4975== by 0x34B2A933: IA__g_signal_emit_by_name (gsignal.c:2312) ==4975== by 0x34EABEA5: gail_widget_size_allocate_gtk (gailwidget.c:958) I was only using it for a few minutes (maybe five or ten). So, if it takes only that long to leak a bit of memory, it is going to be a very nasty leak over the long term. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
I think that this is an at-spi issue.
It seems "any->_value" should be freed at the end of spi_atk_bridge_signal_listener() if any was initialized with spi_init_any_rect()
Is there any chance this could be done before GNOME 2.10? I think this is causing long term leaks in the panel,
I'll look at making a patch; with release-team approval there should be time to integrate if I succeed.
I think I see the problem; the spi_init_any_* family of functions properly set the ->_release flag on the at-spi ANYs, but because we are calling spi_atk_emit_eventv instead of returning these values in skeletons (in this case), the value referred to by '_release' isn't getting automatically freed by the ORB. Possibly the fix is to manually check the _release field and CORBA_free (any->_value) after event emission if (any->_release) is true. Of course this requires that event emission via CORBA/Bonobo be synchronous.
severity was definitely too high
Created attachment 38093 [details] [review] bug which releases any._value programattically please try this patch and see if it substantially improves the situation. It *does* need testing, as it introduces risk.
Am on a school (read windows) computer right now, so I can't test. I can look at this ~7 hrs from now. Could somebody else try valgrinding in the meanwhile to see how this is.
I'm at work so I can't either...
All I see leaking with patch applied is about 600 bytes, after several minutes. But Ben, I don't know what widgets/applets/operations/etc. you were doing when you report the problem, so you're the best person to report whether this helps. I'll re-test w/o the patch to see if I see obvious leakage.
Ben: I reverted the patch and still did not see the leakage with valgrind which you report. I guess I need more info from you about what you tested.
This could be because I have a patch in that makes the clock, wnck, and notification applet inproc. So, by doing valgrind on g-p I was catching the applets too. I'll try the patch when I get home... (4 hrs from now)
The patch is fine; indeed, since the "any" is not being allocated from a skeleton, its value doesn't get freed. The patch should go on CVS.
(Ben reported in email that he was using a patched panel which put the applets in-process; hypothesis is that the leaks were mostly in the applet, which seems reasonable, as the main scenario causing the 'rect' CORBA_Anys is the emission of 'bounds-changed' events, which applets emit frequently).
Ok, I can't seem to repro this for some reason ;-). I might have clicked a button or something in my usage that I didn't on the simple tests. Am still trying...
Hrm, I have not been able to reproduce at all. I tried clicking all the buttons I could see, etc. I could have messed up my build or something, I dunno. I assume this patch would affect other people though, so it'd be nice to get in...