Bug 29790 - CallChannels still awaiting caps when we disconnect are leaked.
Summary: CallChannels still awaiting caps when we disconnect are leaked.
Status: NEW
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 29796
  Show dependency treegraph
 
Reported: 2010-08-24 15:00 UTC by Will Thompson
Modified: 2010-09-30 03:26 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Will Thompson 2010-08-24 15:00:40 UTC
I have been debugging a reference leak in GabbleCallChannel. Here is a branch which fixes it, as well as improving some test machinery which helped me catch it: http://git.collabora.co.uk/?p=user/wjt/telepathy-gabble-wjt.git;a=shortlog;h=refs/heads/get_source_object-refleak

Here is a Wocky branch which fixes similar refleaks in the PubSub code, making its PubSub tests valgrind-clean: http://git.collabora.co.uk/?p=user/wjt/wocky.git;a=commitdiff;h=refs/heads/refleaks
Comment 1 Will Thompson 2010-08-25 03:51:32 UTC
Unfortunately there is a second leak in this stuff.

The media factory calls init_async() on the Call channel. If we're already waiting for the contact's caps, the Call channel waits for them to arrive before succeeding or failing to initialize. If they don't arrive before the connection dies, the signal the call channel is waiting for never arrives, so the async operation never finishes.

The fix ought to be straightforward: in the Call channel, keep track of outstanding init_async() operations. Watch the connection state, and if it changes to Disconnected, fail all the operations, safe in the knowledge that capabilities-discovered will not fire. (Unfortunately, I don't think this is quite true — Disconnected is signalled when we send </stream:stream>, and we might receive the replies before the server sends back </stream:stream> — so some care needs to be taken here.) But I have other things to attend to, I'm afraid.
Comment 2 Simon McVittie 2010-08-25 04:13:27 UTC
(In reply to comment #0)
> http://git.collabora.co.uk/?p=user/wjt/telepathy-gabble-wjt.git;a=shortlog;h=refs/heads/get_source_object-refleak

r+

> http://git.collabora.co.uk/?p=user/wjt/wocky.git;a=commitdiff;h=refs/heads/refleaks

r+, and pre-r+ on the Gabble patch to update to this Wocky :-)

(In reply to comment #1)
> Unfortunately there is a second leak in this stuff.

If the two branches above are harmless, please merge them, retitle and leave this bug open?
Comment 3 Will Thompson 2010-08-25 06:28:49 UTC
Yes! I have done so.
Comment 4 Will Thompson 2010-09-30 03:26:19 UTC
(In reply to comment #1)
> The fix ought to be straightforward: in the Call channel, keep track of
> outstanding init_async() operations. Watch the connection state, and if it
> changes to Disconnected, fail all the operations, safe in the knowledge that
> capabilities-discovered will not fire. (Unfortunately, I don't think this is
> quite true — Disconnected is signalled when we send </stream:stream>, and we
> might receive the replies before the server sends back </stream:stream> — so
> some care needs to be taken here.) But I have other things to attend to, I'm
> afraid.

A better fix would be to replace the gboolean contact_is_media_capable(..., gboolean *wait, ...) functions with

  gboolean gabble_presence_cache_contact_has_caps (cache, handle, caps);

and

  void gabble_presence_cache_contact_has_caps_async(...);
  gboolean ..._finish();

with the former returning immediately, and the latter waiting for the caps to arrive if retrieval is in progress.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.