[Telepathy] [PATCH] Fix crashes in FileTransfer and StreamTubes related to SocketAddressIPv4
drf54321 at gmail.com
Mon May 3 12:11:57 PDT 2010
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
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
> telepathy mailing list
> telepathy at lists.freedesktop.org
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the telepathy