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

Bug #441190 reported by Tim
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
D-Bus
Invalid
Medium
Ubuntu One Client
Invalid
High
dobey
dbus-glib (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

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

Revision history for this message
Tim (t.huetz-deactivatedaccount) wrote :
visibility: private → public
Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt (retraced)

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)

Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt (retraced)
Changed in ubuntuone-client (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
Revision history for this message
Joshua Hoover (joshuahoover) wrote :

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

Changed in ubuntuone-client (Ubuntu):
status: New → Triaged
importance: Medium → High
assignee: nobody → Rodney Dawes (dobey)
Changed in ubuntuone-client:
assignee: nobody → Rodney Dawes (dobey)
importance: Undecided → High
status: New → Triaged
tags: added: ubuntuone-karmic
Revision history for this message
In , James Westby (james-w) wrote :

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

Revision history for this message
dobey (dobey) wrote :

#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.

Changed in ubuntuone-client:
status: Triaged → Invalid
affects: ubuntuone-client (Ubuntu) → dbus (Ubuntu)
Changed in dbus (Ubuntu):
assignee: Rodney Dawes (dobey) → nobody
status: Triaged → New
James Westby (james-w)
affects: dbus (Ubuntu) → dbus-glib (Ubuntu)
Revision history for this message
James Westby (james-w) wrote :

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

Changed in dbus-glib (Ubuntu):
status: New → Triaged
importance: High → Medium
Changed in dbus:
status: Unknown → Confirmed
Changed in dbus:
importance: Unknown → Medium
Changed in dbus:
importance: Medium → Unknown
Changed in dbus:
importance: Unknown → Medium
Changed in dbus:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.