[Bugs] #2955 UNSP: buddy-related signals processed before buddy list is received (was: KeyError: dbus.UInt32(4L) in shell.log)

Sugar Labs Bugs bugtracker-noreply at sugarlabs.org
Sun Jul 10 16:16:26 EDT 2011


#2955: buddy-related signals processed before buddy list is received
------------------------------------------+---------------------------------
    Reporter:  carrott                    |          Owner:  erikos                     
        Type:  defect                     |         Status:  assigned                   
    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by Release Team
   Component:  sugar                      |        Version:  0.92.x                     
    Severity:  Unspecified                |       Keywords:                             
Distribution:  OLPC                       |   Status_field:  Unconfirmed                
------------------------------------------+---------------------------------

Comment(by dsd):

 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.

-- 
Ticket URL: <http://bugs.sugarlabs.org/ticket/2955#comment:2>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system


More information about the Bugs mailing list