ubuntuone-client-applet crashed with SIGSEGV in dbus_watch_set_data()

[Tim]

Binary package hint: ubuntuone-client

Just tried to start "Ubuntu One" and got immediately the segmentation fault. I've upgraded my Ubuntu 9.04 to the current beta last night. Its quite a clean system as I'm not using this computer frequently.

ProblemType: Crash
Architecture: amd64
Date: Sat Oct 3 10:53:42 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/ubuntuone-client-applet
InterpreterPath: /usr/bin/python2.6
Package: ubuntuone-client-gnome 0.96.0-0ubuntu1
ProcCmdline: /usr/bin/python /usr/bin/ubuntuone-client-applet
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-11.38-generic
SegvAnalysis:
 Segfault happened at: 0x7fde8a7006b0: movq $0x0,0x10(%rdi)
 PC (0x7fde8a7006b0) ok
 source "$0x0" ok
 destination "0x10(%rdi)" (0x00000010) not located in a known VMA region (needed writable region)!
SegvReason: writing NULL VMA
Signal: 11
SourcePackage: ubuntuone-client
StacktraceTop:
 ?? () from /usr/lib/libdbus-glib-1.so.2
 dbus_watch_set_data () from /lib/libdbus-1.so.3
 ?? () from /lib/libdbus-1.so.3
 ?? () from /lib/libdbus-1.so.3
 ?? () from /lib/libdbus-1.so.3
Title: ubuntuone-client-applet crashed with SIGSEGV in dbus_watch_set_data()
Uname: Linux 2.6.31-11-generic x86_64
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

[Apport retracing service (apport)]

StacktraceTop:io_handler_watch_freed (data=0x0) at dbus-gmain.c:198
dbus_watch_set_data (watch=0x24b8090, data=0x0,
_dbus_watch_unref (watch=0x0) at dbus-watch.c:131
free_watches (transport=0x2305d70)
socket_disconnect (transport=0x0)

[Joshua Hoover (joshuahoover)]

I'm sorry to hear Ubuntu One is not working properly for you. I'm assigning this to one of our developers to look into further. If he has any questions, he'll follow up here with you. Thank you, Joshua

[James Westby (james-w)]

Hi,

  https://bugs.launchpad.net/ubuntu/+source/dbus-glib/+bug/441190

is what triggered me to look at this. It has the following stacktrace

#0 io_handler_watch_freed (data=0x0) at dbus-gmain.c:198
No locals.
#1 0x00007fde8af8565b in dbus_watch_set_data (watch=0x24b8090, data=0x0,
    free_data_function=0) at dbus-watch.c:602
No locals.
#2 0x00007fde8af85881 in _dbus_watch_unref (watch=0x0) at dbus-watch.c:131
No locals.
#3 0x00007fde8af84e89 in free_watches (transport=0x2305d70)
    at dbus-transport-socket.c:83
No locals.
#4 0x00007fde8af84ee9 in socket_disconnect (transport=0x0)
    at dbus-transport-socket.c:928
No locals.
#5 0x00007fde8af82ea7 in _dbus_transport_disconnect (transport=0x2305d70)
    at dbus-transport.c:494
No locals.
#6 0x00007fde8af838a3 in _dbus_transport_queue_messages (transport=0x2305d70)
    at dbus-transport.c:1137
 status = <value optimized out>

It looks to me as though dbus-glib isn't taking part in dbus' reference counting:

In dbus, as things are being torn down:

  _dbus_watch_unref(...
  .
  .
  .
    if (watch->refcount == 0)
      {
        dbus_watch_set_data (watch, NULL, NULL); /* call free_data_function */

which frees the data.

in dbus-glib

  connection_setup_add_watch(...
  .
  .
  .
    channel = g_io_channel_unix_new (dbus_watch_get_unix_fd (watch));

    handler->source = g_io_create_watch (channel, condition);
    g_source_set_callback (handler->source, (GSourceFunc) io_handler_dispatch, handler,
                           io_handler_source_finalized);

so io_handler_source_finalized will be called as the watch is torn down

  io_handler_source_finalized (gpointer data)
  {
    IOHandler *handler;

    handler = data;

    if (handler->watch)
      dbus_watch_set_data (handler->watch, NULL, NULL);

which frees the data regardless.

This isn't a race, the way io_handler_watch_freed is coded, it will
crash regardless of the ordering here.

I think this isn't an issue for every use, as we are in an exception case in
dbus itself:

    if (_dbus_message_loader_get_is_corrupted (transport->loader))
    {
      _dbus_verbose ("Corrupted message stream, disconnecting\n");
      _dbus_transport_disconnect (transport);

As for a fix, I'm not sure, should dbus-glib take part in the refcounting,
or just not bother freeing the data and rely on dbus to do it?

Thanks,

James

[dobey (dobey)]

#2 0x00007fde8af85881 in _dbus_watch_unref (watch=0x0) at dbus-watch.c:131

Looks like an issue in dbus or dbus-glib, and not ubuntu one.

[James Westby (james-w)]

It looks to me as though dbus-glib isn't taking part in dbus' reference counting:

In dbus, as things are being torn down:

  _dbus_watch_unref(...
  .
  .
  .
    if (watch->refcount == 0)
      {
        dbus_watch_set_data (watch, NULL, NULL); /* call free_data_function */

which frees the data.

in dbus-glib

  connection_setup_add_watch(...
  .
  .
  .
    channel = g_io_channel_unix_new (dbus_watch_get_unix_fd (watch));

    handler->source = g_io_create_watch (channel, condition);
    g_source_set_callback (handler->source, (GSourceFunc) io_handler_dispatch, handler,
                           io_handler_source_finalized);

so io_handler_source_finalized will be called as the watch is torn down

  io_handler_source_finalized (gpointer data)
  {
    IOHandler *handler;

    handler = data;

    if (handler->watch)
      dbus_watch_set_data (handler->watch, NULL, NULL);

which frees the data regardless.

I think this isn't an issue for every use, as we are in an exception case in
dbus itself:

    if (_dbus_message_loader_get_is_corrupted (transport->loader))
    {
      _dbus_verbose ("Corrupted message stream, disconnecting\n");
      _dbus_transport_disconnect (transport);

As for a fix, I'm not sure, should dbus-glib take part in the refcounting,
or just not bother freeing the data and rely on dbus to do it?

Thanks,

James