Opened 13 years ago

Closed 11 years ago

#2955 closed defect (fixed)

buddy-related signals processed before buddy list is received

Reported by: carrott Owned by: erikos
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Sugar Version: 0.92.x
Severity: Unspecified Keywords:
Cc: Distribution/OS: OLPC
Bug Status: Unconfirmed


os871 and os872 (11.2.0 I think) on XO 1.0

We see this exception in shell.log on a regular basis on all our XO-1.0s.

310169861.125557 ERROR dbus.connection: Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/dbus/", line 214, in maybe_handle_message
    self._handler(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/jarabe/model/", line 430, in __buddy_info_updated_cb
    self.emit('buddy-updated', self._buddy_handles[handle], properties)
KeyError: dbus.UInt32(4L)

Attachments (1)

0001-sl-2955.patch (2.0 KB) - added by ajay_garg 12 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 13 years ago by sascha_silbe

  • Component changed from untriaged to sugar
  • Owner set to erikos
  • Status changed from new to assigned

comment:2 Changed 13 years ago by dsd

  • Summary changed from KeyError: dbus.UInt32(4L) in shell.log to buddy-related signals processed before buddy list is received

I can reproduce this too, on connecting to

OLPC OS 11.2.0 build 871, sugar 0.92.2

There is a problem in model/ class Account method __get_self_handle_cb

This method connects a load of signals (such as __buddy_info_updated_cb which is getting called here) and then afterwards (via channel.Get(Members)) requests a list of all connected buddys at which point it adds them to its internal model.

What is happening here is that some signals are being received before the list of connected buddys has been downloaded and processed.

I was going to suggest that this be fixed by only connecting signals after the the buddy list has been received. That would be upon completion of __get_contact_attributes_cb. However, I think this would be racy as well: what if a buddy disconnects immediately after the members list has been received, but before the signals have been connected?

So I think the correct approach here is to harden up all of the signal handlers so that they can happily do nothing if the buddy they are trying to process is not (yet) known by the model. I see that some of them already do this to an extent, via if handle in self._buddy_handles checks.

comment:4 Changed 12 years ago by ajay_garg

Attaching the patch, after changing patch description (courtesy Sascha).

Changed 12 years ago by ajay_garg

comment:5 Changed 11 years ago by Walter Bender

  • Resolution set to fixed
  • Status changed from assigned to closed

buddy-updated signal emitted before buddy list is received

Fixes #2955

This patch, originally authored by Ajay Garg, fixes a problem where
buddy-updated signals were emitted before the buddy handle had been
added to the buddy handle list.

Changeset: 372401e66afe730fcff90d17301150cb8d21f25c

Note: See TracTickets for help on using tickets.