Ubuntu
unity8 package

[TOPBLOCKER] Apps scope empty on boot

Bug #1382039 reported by Michał Sawicz
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
qtmir (Ubuntu)
Fix Released
Critical
Ted Gould
qtmir (Ubuntu RTM)
Fix Released
Undecided
Unassigned
unity-scope-click (Ubuntu)
Invalid
Undecided
Unassigned
unity-scopes-api (Ubuntu)
Invalid
Undecided
Michi Henning
unity-scopes-shell (Ubuntu)
Invalid
Critical
Unassigned
unity8 (Ubuntu)
Invalid
Critical
Albert Astals Cid

Bug Description

Several people reported today that the apps scope came up empty on boot. A pull-to-refresh makes results come in again.

Note: it seems the problem is more likely to happen if you wait for at least 1 minute after reboot, and then unlock your device.

See original description

Related branches

lp:~ted/qtmir/ual-pause
Gerry Boland (community): Approve
PS Jenkins bot (community): Approve (continuous-integration)
Diff: 1079 lines (+75/-689)
16 files modified
src/modules/Unity/Application/Application.pro (+0/-2)
src/modules/Unity/Application/application.cpp (+2/-2)
src/modules/Unity/Application/applicationcontroller.h (+3/-0)
src/modules/Unity/Application/processcontroller.cpp (+0/-231)
src/modules/Unity/Application/processcontroller.h (+0/-62)
src/modules/Unity/Application/taskcontroller.cpp (+12/-69)
src/modules/Unity/Application/taskcontroller.h (+3/-7)
src/modules/Unity/Application/upstart/applicationcontroller.cpp (+19/-0)
src/modules/Unity/Application/upstart/applicationcontroller.h (+3/-0)
tests/modules/ApplicationManager/application_manager_test.cpp (+0/-18)
tests/modules/TaskController/taskcontroller_test.cpp (+4/-198)
tests/modules/common/common.pri (+1/-3)
tests/modules/common/mock_application_controller.h (+26/-2)
tests/modules/common/mock_oom_controller.h (+0/-34)
tests/modules/common/mock_process_controller.h (+0/-45)
tests/modules/common/qtmir_test.h (+2/-16)
Revision history for this message
Pete Woods (pete-woods) wrote :

Probably worth throwing the shell plugin in as a second suspect.

tags: added: rtm14
Revision history for this message
Pete Woods (pete-woods) wrote :

I have seen this on my N4 with image 288. Both on first boot, and after subsequent reboots.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in unity-scopes-shell (Ubuntu):
status: New → Confirmed
Revision history for this message
Pete Woods (pete-woods) wrote :

It's also not just the click scope that fails to load. I have seen the results missing from both the music and video aggregator scopes.

Revision history for this message
Victor Tuson Palau (vtuson) wrote :

is this not a dupe of https://bugs.launchpad.net/bugs/1374481

Pat McGowan (pat-mcgowan)
tags: added: touch-2014-10-23
Revision history for this message
Michał Sawicz (saviq) wrote :

Yes, I expect this to be the same.

Revision history for this message
Michał Sawicz (saviq) wrote :

Although the solution to the other bug does not make me positive about this. Please un-dupe if needed.

Revision history for this message
Pete Woods (pete-woods) wrote :

I don't think this is the same underlying bug.

Revision history for this message
Pete Woods (pete-woods) wrote :

The other one is more about location data being missing -> leads to nearby scope returning no results.

kevin gunn (kgunn72)
Changed in unity-scopes-shell (Ubuntu):
importance: Undecided → Critical
Revision history for this message
kevin gunn (kgunn72) wrote :

@saviq - just assigning so it doesn't get lost, since pat seems to request it make the next flight 10/23

Changed in unity8 (Ubuntu):
assignee: nobody → Michał Sawicz (saviq)
Michał Sawicz (saviq)
Changed in unity8 (Ubuntu):
assignee: Michał Sawicz (saviq) → Albert Astals Cid (aacid)
Revision history for this message
Paweł Stołowski (stolowski) wrote :

Our latest findings (we added more debug in different places) point at unity-scopes-api. This is still under investigation.

Revision history for this message
Paweł Stołowski (stolowski) wrote :
Revision history for this message
Paweł Stołowski (stolowski) wrote :

The attached scoperegistry and unity8-dash log files show that result pushes from clickscope are not lost / not received by shell plugin.

Revision history for this message
Albert Astals Cid (aacid) wrote :

Pawel, I can't parse that last sentence, how can the be "not lost" but also "not received"?

Revision history for this message
Paweł Stołowski (stolowski) wrote :

Sorry, a typo. The results from clickscope seem to be lost (not received).

Paweł Stołowski (stolowski)
description: updated
Alexander Sack (asac)
summary: - Apps scope empty on boot
+ [TOPBLOCKER] Apps scope empty on boot
Albert Astals Cid (aacid)
Changed in unity8 (Ubuntu):
status: Triaged → Invalid
Michi Henning (michihenning)
Changed in unity-scopes-api (Ubuntu):
status: New → Confirmed
assignee: nobody → Michi Henning (michihenning)
status: Confirmed → In Progress
Paweł Stołowski (stolowski)
Changed in unity-scope-click (Ubuntu):
status: New → Invalid
Changed in unity-scopes-shell (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Paweł Stołowski (stolowski) wrote :

Marking as 'incomplete' in unity-scopes-shell as to our best knowledge the problem is only in unity-scopes-api.

Michi Henning (michihenning)
Changed in unity-scopes-api (Ubuntu):
status: In Progress → Invalid
Revision history for this message
Michi Henning (michihenning) wrote :

This is not a bug in unity-scopes-api. The problem was that unity8-dash has become an app recently, and qtmir sends SIGSTOP five seconds after the greeter appears. Suspending the dash at random unpredictable times is a big no-no because the signal can strike while a request-reply interaction with a scope is in flight, causing the RPC to time out when the dash is eventually resumed. It can also happen that the signal arrives while results are trickling in from a scope, causing either no results at all to appear or, alternatively, truncating the results at some random point.

After installing qtmir packages I got from Ted that do not suspend the dash, things work perfectly fine.

I also checked CPU consumption of the dash and, while the dash isn't doing any work, it is completely quiescent. The CPU consumption problem that was observed earlier was almost certainly related to bug #1364464 and bug #1374206, both of which are fixed.

I think qtmir should change the policy and exclude unity8-dash from the list of apps that are suspended. We are the authors of unity8-dash and, if the dash bleeds CPU cycles, we should fix the dash rather than plastering over the problem by suspending the dash.

Right now, the dash is fine and does not use CPU when idle.

Changed in unity-scopes-shell (Ubuntu):
status: Incomplete → Invalid
Changed in qtmir (Ubuntu):
status: New → Confirmed
Revision history for this message
Gerry Boland (gerboland) wrote :

Ok, am happy to land Ted's branch.

Michał Sawicz (saviq)
Changed in qtmir (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Critical
assignee: nobody → Ted Gould (ted)
Revision history for this message
Alexander Sack (asac) wrote :

Hello, Hello, seems this is stuck'ish again?

Who needs doing what here to get us to a good app scope back asap?

Thanks!

 - Alexander

Revision history for this message
Michi Henning (michihenning) wrote :

There is a fix in qtmir already, but I suspect it hasn't made it into the image yet?

Revision history for this message
Thomas Strehl (strehl-t) wrote :

It's in rtm silo 15. Saviq will land tomorrow.

Michał Sawicz (saviq)
Changed in qtmir (Ubuntu):
status: Triaged → In Progress
Changed in qtmir (Ubuntu RTM):
status: New → In Progress
Michał Sawicz (saviq)
Changed in qtmir (Ubuntu RTM):
status: In Progress → Fix Released
Changed in qtmir (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.