GNOME Bugzilla – Bug 635105
Empathy is eating all the memory
Last modified: 2011-08-29 10:12:43 UTC
I was running master and went out for dinner. When I was back (40 minutes later), Empathy was using a shit load of memory. I interrupted it in gdb and got this trace:
+ Trace 224726
Created attachment 174772 [details] [review] http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/leaks-635105 libempathy-gtk/empathy-cell-renderer-text.c | 1 + libempathy-gtk/empathy-individual-store.c | 21 ++++++++++++++------- 2 files changed, 15 insertions(+), 7 deletions(-)
+1
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
I'm still seeing this bug from time to time :(
I wonder if the fix for bug #637136 will fix this, if it's a folks bug and was triggered by going offline?
Each time I observed this bug, all my accounts were connected and I didn't change my presence.
It looks like this also isn't bug 640551 or bug 640554, unfortunately.
So, this is obviously a serious bug that I have yet to reproduce. And nobody seems to know exactly what triggers it. Could everyone who has ever hit this bug run Empathy with FOLKS_DEBUG=all and report its output here when it happens? I'm guessing it will be something obvious in the output (like an aggregation cycle). In the meantime, I'll comb through the aggregator code to see if there's anything that could cause some sort of infinite loop (other than what we fixed for bug 637136).
backtrace (found using (ulimit -v 600000 ; gdb -x ~/src/telepathy-psyke/tests/tools/run_and_bt.gdb --args empathy) ) is below. ] GLib-ERROR **: /tmp/buildd/glib2.0-2.27.91/./glib/gmem.c:202: failed to allocate 72 bytes aborting... Program received signal SIGTRAP, Trace/breakpoint trap.
+ Trace 225777
Thread 140736840423184 (LWP 12020)
A debugging session is active. Inferior 1 [process 17543] will be killed. Quit anyway? (y or n) [answered Y; input not from terminal]
I just reproduced this bug with FOLKS_DEBUG=all and the console wasn't flooded by debug output. :\
(In reply to comment #9) > GLib-ERROR **: /tmp/buildd/glib2.0-2.27.91/./glib/gmem.c:202: failed to > allocate 72 bytes > aborting... > > Program received signal SIGTRAP, Trace/breakpoint trap. > Hmm - I'm not sure this is necessarily related. Or do you mean the allocation failed due to OOM? At any rate, I'm not sure what the backtrace is telling us.
(In reply to comment #10) > I just reproduced this bug with FOLKS_DEBUG=all and the console wasn't flooded > by debug output. :\ Could you email it to me anyhow? Maybe there's some obvious pattern I would notice.
We finally got it ! For the record, the fix is: commit 9503c4aa28b9a4215e3e325a31b500f2c78b712a Author: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk> Date: Tue Feb 1 11:34:37 2011 +0100 individual-widget: connect on the notify::client-types only once Reconnecting a signal while you are handling it isn't exactly a good idea as it will result in an infinite loop eating all your memory (#635105). This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.