[Bug 31412] crashes during disconnection if a PEP alias request is in-flight

[bugzilla-daemon at freedesktop.org]

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

--- Comment #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-11-08 03:48:51 PST ---
(In reply to comment #3)
> Does not making vCard requests until we're Connected break people asking for
> the alias or whatever while we're Connecting?

As far as I can tell, no: in particular, our API to look up aliases requires
handles, and you can't reliably have handles until connected.

> +      /* FIXME: what if vcard_manager is NULL? */
>        if (request->vcard_requests[i] != NULL)
>          gabble_vcard_manager_cancel_request (request->conn->vcard_manager,
>              request->vcard_requests[i]);
> 
> What if, indeed. :/ I've never seen this crashing... ;-)

Yeah, this is technically wrong, but I suspect the destruction order
coincidentally makes it OK... this branch certainly isn't a regression in that
respect, and I think getting it fully correct is a job for the development
branch.

> +    # We disconnect too soon to get a reply
> I think there's a helper method for this.

I'll look into it.

> +    # check that Gabble hasn't crashed
> +    cm = bus.get_object(cs.CM + '.gabble',
> +            '/' + cs.CM.replace('.', '/') + '/gabble')
> +    call_async(q, dbus.Interface(cm, cs.CM), 'ListProtocols')
> +    q.expect('dbus-return', method='ListProtocols')
> 
> Should we make sync_dbus() use this and just call that? (Would its current
> implementation do?)

I don't think they're conceptually the same thing: sync_dbus processes all
queued D-Bus messages, whereas this checks that the CM hasn't crashed. It
happens to be the case that both do both in practice, though, so yes I could
use its current implementation.

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