Opened 12 years ago
Closed 10 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 |
Description
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/connection.py", line 214, in maybe_handle_message self._handler(*args, **kwargs) File "/usr/lib/python2.7/site-packages/jarabe/model/neighborhood.py", line 430, in __buddy_info_updated_cb self.emit('buddy-updated', self._buddy_handles[handle], properties) KeyError: dbus.UInt32(4L)
Attachments (1)
Change History (6)
comment:1 Changed 12 years ago by sascha_silbe
- Component changed from untriaged to sugar
- Owner set to erikos
- Status changed from new to assigned
comment:2 Changed 12 years ago by dsd
- Summary changed from KeyError: dbus.UInt32(4L) in shell.log to buddy-related signals processed before buddy list is received
comment:3 Changed 12 years ago by ajay_garg
Patch at ::
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 10 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.
I can reproduce this too, on connecting to jabber.sugarlabs.org
OLPC OS 11.2.0 build 871, sugar 0.92.2
There is a problem in model/neighborhood.py 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.