[Bug 40283] Crash when a client needs recovery

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=40283

--- Comment #3 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2011-08-23 02:39:03 PDT ---
(In reply to comment #0)
> 1) The big one: when an approver claims a channel, MC should insert a valid
> well-known-name for it in the table.

Why? What is this well-known name useful for?

If the channel is "brought to the foreground" (I think this is called
"reinvoking" inside MC?) with EnsureChannels, we'll need some sort of
well-known name for the approver/handler process, but if we're picking
arbitrarily among its well-known names, we can do that equally well later, when
the EnsureChannels call actually happens. I believe the EnsureChannels code
already knows how to do this, in fact.

Also, we should pick a name that is a Handler - if a process owns
o.fd.T.Client.GnomeShellHandler (a Handler) and
o.fd.T.Client.GnomeShellApprover (an Approver), we want to choose the Handler,
not the Approver (and if none of the names are Handlers, we can't call
HandleChannels). I believe the EnsureChannels code already does this, too.

Note that processes with no well-known names at all can theoretically Claim() a
channel - although this is only valid if they're about to Close() it, because
without being a Handler, the client won't be able to list the channel in its
HandledChannels.

(Also: the indentation of the first patch seems to have got lost or something.)

> 2) in recovery, if a well-known-name of an handler is NULL, it should not
> crash

This is definitely true, though.

Could you/someone make a regression test for this, please? I agree this needs
fixing, but I don't think this branch is the right fix.

I think your second patch (on its own) might well be the right fix for this.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.