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
Fixing this bug would be helpful for the channel-creation API in Bug #13422 to do the right thing, too. See attached branch.
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)?
everything else looks reasonable.
(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.
looks good, ship it.
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.