Bug 24645

Summary: Try harder to reinvoke the same Handler well-known name
Product: Telepathy Reporter: Simon McVittie <smcv>
Component: mission-controlAssignee: Simon McVittie <smcv>
Status: RESOLVED FIXED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: enhancement    
Priority: medium CC: guillaume.desmottes, vivek
Version: unspecifiedKeywords: 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.