Bug 24645

Summary:	Try harder to reinvoke the same Handler well-known name
Product:	Telepathy	Reporter:	Simon McVittie <smcv>
Component:	mission-control	Assignee:	Simon McVittie <smcv>
Status:	RESOLVED FIXED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	enhancement
Priority:	medium	CC:	guillaume.desmottes, vivek
Version:	unspecified	Keywords:	patch
Hardware:	Other
OS:	All
URL:	http://git.collabora.co.uk/?p=user/smcv/telepathy-mission-control-smcv.git;a=shortlog;h=refs/heads/rescue-mission
Whiteboard:	review+
i915 platform:		i915 features:
Bug Depends on:	24120
Bug Blocks:

Description Simon McVittie 2009-10-20 11:04:42 UTC

When reinvoking a Handler for EnsureChannels, as noted on Bug #24120, MC can easily pick a different well-known name (and hence object path) within the same unique name.

> There are two ways that the new logic could pick the wrong head from such a
> hydra:
> 
> * The handler has put up an extra head that matches the channel better; that

(or just as well, and happens to be sorted first)

> new head catches the channel, instead of it going to the less specific head
> (this would happen if the fake Empathy in dispatcher/capture-bundle.py had a
> channel redispatched to it)
> 
> * The handler previously had an extra head that matched the channel better, but
> it has cut off that head (I can't think of a real-world use case for this); due
> to the fallback behaviour you propose, your logic and mine are effectively
> equivalent here

Comment 1 Simon McVittie 2010-07-16 05:09:20 UTC

Fixing this bug would be helpful for the channel-creation API in Bug #13422 to do the right thing, too. See attached branch.

Comment 2 Vivek Dasmohapatra 2010-07-16 11:18:13 UTC

does http://git.collabora.co.uk/?p=user/smcv/telepathy-mission-control-smcv.git;a=commitdiff_plain;h=286307447f8977a4fddf3dbee0b7374b88c3e57d
potentially leak when we collide?

If we allocate the new path once per attempt with g_strdup_printf, the 
g_free should be hauled into the loop (or am I missing something)?

Comment 3 Vivek Dasmohapatra 2010-07-16 11:27:24 UTC

everything else looks reasonable.

Comment 4 Simon McVittie 2010-07-19 02:56:17 UTC

(In reply to comment #2)
> If we allocate the new path once per attempt with g_strdup_printf, the 
> g_free should be hauled into the loop (or am I missing something)?

Well spotted, fixed. I've narrowed the scope of some local variables too, to make it more obviously correct.

Comment 5 Vivek Dasmohapatra 2010-07-19 04:04:11 UTC

looks good, ship it.

Comment 6 Simon McVittie 2010-07-19 04:34:22 UTC

Fixed in git for 5.5.3.

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.