Telepathy-butterfly leaks memory

telepathy-butterfly waas updated yesterday to 0.5.9. It still leaks memory.
Please let me know what other data I can provide to assist with this issue

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a valgrind log following the instructions at https://wiki.ubuntu.com/Valgrind and attach the file to the bug report. This will greatly help us in tracking down your problem.

Hi Sebastien,

Please let me know what other information is required to get this bug out of "incomplete" status.

Thanks,
Yoav

Sorry, I didn't really read your message the first time...

Since the telepathy-butterfly process is activated automatically from within the Empathy app, I could not run it with valgrind.
I tried to replace it's python script with the attached script, but it failed to run that way.
I'm currently trying a different method - dumping the various objects inside the telepathy-butterfly script and see which one is leaking.

You can launch telepathy-butterfly manually before empathy does it see http://live.gnome.org/Empathy/Debugging

Hello,
I have had Empathy up for about 4 days and right now memory usage is at 1836 MB. Certainly points to a leak. I will start it again and let it run over the weekend.

Vancouverite
10.04 64 bit

@Vancouverite - I'm glad to see I'm not the only one suffering from this...
I tried to run telepathy-butterfly with the usual memory leak detection tools and it did not work (i.e. empathy did not connect to MSN).
Now I'm trying to debug it from within the python code. I added a thread that prints out all objects including their sizes.
The leak seems to be related to a list of dictionaries, but I can't figure out their names/containing variables/etc.
Any advice on how to further debug this would be appreciated...

Replicated leaking in Maverick with latest updates from proposed, The work memory for this eager process grew up to 2.6GB. It goes connected /disconnected and crying about some gmail certificate which I have to validate manually...

alfabravo@alfabravoTiger:~$ uname -a
Linux alfabravoTiger 2.6.35-22-generic #34-Ubuntu SMP Sun Oct 10 09:26:05 UTC 2010 x86_64 GNU/Linux

alfabravo@alfabravoTiger:~$ empathy -v
Empathy 2.32.0.1

@Yoav, Have you seen comment #6 ?
You dont need the python script, just kill everything and start telepathy-butterfly first in valgrind before starting empathy.

@all, We *need* a valgrind to fix this bug, kindly obtain the valgrind. Screenshots about the problem do not help identify the cause of the bug.

I already have Valgrind but couldn't figure out how to start telepathy-butterfly in it. If someone helps me a bit on this, I can kindly drive myself to memory-leakingness suffering "for the good of the game" :-)

First quit empathy

$ killall mission-control telepathy-butterfly telepathy-stream-engine
 or any other telepathy- running, try to look in the sys monitor.

Then run valgrind using:
$ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=valgrind.log /usr/lib/telepathy/telepathy-butterfly

@Vish - I have already tried that in the past.
When I'm not starting up Empathy in parallel I get the following message:
INFO:Butterfly.ConnectionManager:Connection manager created
INFO:Butterfly:No connection received - quitting
INFO:Butterfly.ConnectionManager:Connection manager quitting

When I am starting empathy in parallel I'm getting:
WARNING:Butterfly:Failed to acquire bus name, connection manager already running?

In both cases the telepathy-butterfly process immediately quits.
I have tried internal Python debugging, but did not get very far for now (I have can deal with that only in my spare time which is sparse).

If you have any more advice regarding this bug, I'd highly appreciate it. Maybe there is some way to sync both processes?

Indeed, that approach to use valgrind on telepathy-butterfly didn't work properly and the thing never got to show up on running processes.
Nevertheless, I submit the resulting log.

PS. I managed to force telepathy-butterfly to grow up consistently by disconnecting/connecting my msn account. It grows 2MB per reconnection. Hope we find a way to point out the thing clearer.

I've followed the instructions stated here: http://live.gnome.org/Empathy/Debugging

Thru the debug window, I got the attatched log for telepathy-butterfly. Hope it rings a bell for someone (regexp all the way obfuscating emails!! rats!).

Thanks for the debugging info, This bug is an upstream one and it would be quite helpful if somebody experiencing it could send the bug the to the people writing the software. You can learn more about how to do this for various upstreams at https://wiki.ubuntu.com/Bugs/Upstream/Freedesktop .
Once submitted upstream , do report back here with the upstream bug number.Thanks in advance!

I have submitted this bug with upstream: https://bugs.freedesktop.org/show_bug.cgi?id=31936
A patch that works around the problem is attached.

Copying the bug details here:
_______________________
Papyon 0.4.6 sends out requests to MSN's server that cause the server to return
a 400 HTTP response ("Bad Request").
When such responses are received, telepathy-butterfly (through it's use of
papyon) suffers from a huge memory leak. (about 200MB per hour on average)

Detailes:
In http://support.microsoft.com/kb/826437 you can see that the .Net framework
1.1 does not accept requests that contains ":" in the host name AND "&" in the
URL because of a bug.
Papyon sends requests to port 80 to a URL of the form:
http://65.54.48.32:80/gateway/gateway.dll?Action=poll&SessionID=962514443.0
The MSN server then responds to these responses with a '400 Bad Request'
response.
These responses also result in a huge memory leak.

Workaround:
Since it is not necessary to send the port number with the URL when the port
number is 80, I created a patch that avoids sending it in this case. This helps
to avoid the 400 responses as well as the memory leak.
This attached patch relates to the papyon/gnet/protocol directory

Further details:
OS - Ubuntu 10.04 64 bit with all latest updates.

Thanks for the patch and for forwarding the bug upstream.

Let's wait for upstream comments on the patch.

upstream asked questions on the bug your sent, could you reply to those?