[Telepathy] [PATCH] Fix crashes in FileTransfer and StreamTubes related to SocketAddressIPv4

[Dario Freddi]

On Monday 03 May 2010 20:54:17 Simon McVittie wrote:
> Does telepathy-qt4 actually *crash* when the type is not as expected, or
> just not work? If it crashes, that's a separate bug (D-Bus applications
> shouldn't crash, regardless of what they receive from D-Bus). If it just
> doesn't work, that's OK.

Tp-Qt4 actually crashes, but *not* due to QtDBus. qdbus_cast, by default, 
returns a null pointer if the cast does not succeed. This means that the 
structure is referring to a null pointer and hence triggers a crash as soon as 
it gets accessed. So QtDBus is not leading to a crash - hence my proposal for 
the workaround using 2 different structs.

For now, we can simply push a quick fix which avoid the crash - which is just 
checking if *addr == 0.

> 
> On Mon, 03 May 2010 at 20:18:18 +0200, Dario Freddi wrote:
> > It would be a workaround changing the spec _only_ in tp-qt4, where we
> > would actually end up having an inconsistency.
> 
> Right, if telepathy-qt4's spec/ directory differs from the official
> language-neutral one in telepathy-spec then that's a bug.
> 
> The problem is that telepathy-glib claims to implement the language-neutral
> spec, but can't (because dbus-glib can't); so either we need to change the
> language-neutral spec to what we've (in practice) always implemented, or
> special-case the 16-bit types.
> 
> Changing telepathy-spec would break interop with any CM that implements the
> spec as written, but I don't think we have any non-GLib connection managers
> that do File Transfer or Tubes, so the worst that can happen is that
> avatar requirements from the Python CMs (Butterfly, Sunshine etc.) are
> broken.

Yeah, I agree completely - also consider that we can change only the methods 
which return a q. Passing a q as an argument is not a problem, even if the day 
a CM gets written with tp-qt4, the above assumption is no longer true. So the 
long term solution is changing q->u everywhere in the spec.

> 
> > The real solutions are:
> >  * Apply my changes to the whole Telepathy spec
> >  * Fix dbus-glib and make all CM adhere to the spec
> > 
> > If both of them are not possible, I can add a real workaround, which
> > consists in adding another structure with signature (su) as a private
> > type, and cast to that structure if casting to (sq) fails.
> 
> Fixing dbus-glib isn't really feasible either (it'd be an ABI break in
> dbus-glib!), so we either dig up my branch from fd.o #20776 or your
> presumably-equivalent changes (i.e. change telepathy-spec to match what we
> always implemented in GLib-land), or work around the few current 16-bit
> types in telepathy-qt4 and avoid adding any more, or both.

Ok - let me know what the final decision will be, so we can act accordingly :)

> 
> > IMHO, using a different spec for tp-qt4 and tp-glib is asking for trouble
> 
> Yes, I agree. The problem is that Telepathy happened first in GLib and
> Python; dbus-glib is unable to implement the language-neutral spec as
> designed, but because Python is extremely permissive about types, nobody
> noticed.
> 
>     Simon
> _______________________________________________
> telepathy mailing list
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/telepathy/attachments/20100503/bca5e37d/attachment.pgp>