#12272 NORM 13.1.0: Activity updater freezes

[Zarro Boogs per Child]

#12272: Activity updater freezes
---------------------------------------+------------------------------------
           Reporter:  bert             |       Owner:  dsd                              
               Type:  defect           |      Status:  assigned                         
           Priority:  normal           |   Milestone:  13.1.0                           
          Component:  upgrade utility  |     Version:  Development build as of this date
         Resolution:                   |    Keywords:                                   
        Next_action:  never set        |    Verified:  0                                
Deployment_affected:                   |   Blockedby:                                   
           Blocking:                   |  
---------------------------------------+------------------------------------

Comment(by dsd):

 I haven't reproduced the hang yet, but something odd is happening which is
 probably related. After updating the same set of 5 activities, and then
 trying to exit the updater, Sugar stops drawing itself properly. Things
 respond to the mouse but the UI is "blank" and doesn't refresh.

 This doesn't happen every time, but it does happen most of the time, using
 the same activity upgrades as a test:
 {{{
 rm -rf /home/olpc/Activities/HelloWorld.activity
 /home/olpc/Activities/Calculate.activity/
 /home/olpc/Activities/Ruler.activity/ /home/olpc/Activities/Chat.activity/
 /home/olpc/Activities/Moon.activity/
 }}}

 So far I have determined its not related to the refresh that is done after
 the activities are updated. It is triggered by something inside
 b.install_or_upgrade().

 It's not the code that sets the favourite flag inside install_or_upgrade,
 nor the activity monitoring code in bundleregistry.

 It might be related to the fact that we call into the bundleregistry from
 the upgrade thread, but bundleregistry doesn't seem to have any thread
 safety. Not that I can explain how lack of thread safety would result in
 this, but it may be worth trying a GIOScheduler-based approach for a more
 principled design (GIOSchedulerJobs can call back into the mainloop with
 relative ease).

-- 
Ticket URL: <http://dev.laptop.org/ticket/12272#comment:5>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system