registry team mailing list archive

[Bug Watch Updater <441190@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 1 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=24412.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2009-10-08T17:10:37+00:00 James Westby 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

Reply at: https://bugs.launchpad.net/dbus/+bug/441190/comments/5


** Changed in: dbus
   Importance: Unknown => Medium

-- 
ubuntuone-client-applet crashed with SIGSEGV in dbus_watch_set_data()
https://bugs.launchpad.net/bugs/441190
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for D-Bus.