[regression] Device locks randomly on welcome screen

Bug #1339700 reported by Dave Morley
32
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Mir
Fix Released
High
Mir development team
0.4
Fix Released
High
Mir development team
mir (Ubuntu)
Fix Released
High
Unassigned
unity8 (Ubuntu)
Invalid
Critical
Unassigned

Bug Description

Unity8 welcome screen will occasionally lock.

Lock effects:
No launcher available
Can't swipe left or right
Can't drag down indicators
Doesn't recover from tapping the power button a couple of times.

Randomness:
Locks so far have been happening on and off from image U114
The phone seems to lock up for me more on waking from suspend, however rsalveti pointed out that for him it happened on phone hang up.

For me the lock happened a couple of times over the weekend images U114 and U115, and then not again till today U122.

Manta seems more prone to lock ups that flo or mako.

STEPS: (It seems flo has an issue identical when opening settings app)
On flo update to U123
1. Once updated, open the settings app
This seems to land you in the state described. Apparently this is only a temporary version if you leave the device for a while it will unlock.

But I think that is possibly because you are moved away from the app and it is unlocked by the system waking from suspend possibly.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: unity8 7.90+14.10.20140707-0ubuntu1
Uname: Linux 3.4.0-5-mako armv7l
ApportVersion: 2.14.4-0ubuntu1
Architecture: armhf
Date: Wed Jul 9 13:48:14 2014
InstallationDate: Installed on 2014-07-09 (0 days ago)
InstallationMedia: Ubuntu Utopic Unicorn (development branch) - armhf (20140709-020204)
SourcePackage: unity8
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Revision history for this message
Dave Morley (davmor2) wrote :
Changed in unity8 (Ubuntu):
status: New → Confirmed
Revision history for this message
Alan Pope 🍺🐧🐱 🦄 (popey) wrote :

I had this today on #119 on mako.

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

A bit more info:

- apps can't be launched (hang at startup)
- can't call (display powers up, no sound or notification)
- I couldn't connect from gdb ("A program is being debugged already. Kill it? (y or n)")
- unity8 consumes some CPU (but not a lot, like 14%)
- SIGTERM didn't help
- SIGSEGV didn't result in a .crash file :|

Revision history for this message
Dave Morley (davmor2) wrote :
Revision history for this message
Julien Funk (jaboing) wrote :

This has been happening to me, more importantly though, when a fix does go in I would like to see an automated test go in along with it.

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

More symbols from mzanetti: http://paste.ubuntu.com/7771898/

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

Suspicious things from the above (chicken'n'egg possible):

Thread 33: __invoke<mir::scene::SnapshottingFunctor>
Should only be called occasionally, if this locked up, would suggest something in app screenshotting?

Thread 31: SessionAuthorizer::requestAuthorizationForSession
This one should usually only be called on session startup, definitely not when stuff's locked up...

Thread 7: wait<mir::frontend::Surface::swap_buffers_blocking
Should this be there at all? Wonder if this means rendering didn't resume from suspend?

Revision history for this message
Michael Zanetti (mzanetti) wrote :

This is the most I could get out of it: http://paste.ubuntu.com/7772064

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

My trace out of manta: http://paste.ubuntu.com/7772239/

Revision history for this message
Alberto Aguirre (albaguirre) wrote :

Yeah it's a deadlock in mir, specifically between the compositor Thread and the main loop:

The TimeoutFrameDroppingPolicy has timedout, so it owns the internal alarm mutex and attemps to drop a frame, so it waits for the BufferQueue mutex.

The compositor thread is releasing a buffer, so it calls BufferQeueue::compositor_release, which owns the BufferQueue mutex and attempts to update the TimeoutFrameDroppingPolicy (since a buffer is being freed) but it waits to own the internal alarm mutex so deadlock.

Changed in mir:
importance: Undecided → High
status: New → Confirmed
Michał Sawicz (saviq)
Changed in unity8 (Ubuntu):
status: Confirmed → Invalid
kevin gunn (kgunn72)
Changed in mir:
assignee: nobody → Alberto Aguirre (albaguirre)
Michał Sawicz (saviq)
Changed in mir:
status: Confirmed → In Progress
Changed in mir:
milestone: none → 0.5.0
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

The two relevant commits appeared in Mir 0.3.0 and then 0.4.0:

------------------------------------------------------------
revno: 1725 [merge]
committer: Alan Griffiths <email address hidden>
branch nick: development-branch
timestamp: Thu 2014-06-26 17:06:24 +0100
message:
  server: Avoid race condition in AlarmImpl
------------------------------------------------------------
...
------------------------------------------------------------
revno: 1675 [merge]
author: Alberto Aguirre <email address hidden>
committer: Tarmac
branch nick: development-branch
timestamp: Tue 2014-06-03 17:49:45 +0000
message:
  Allow buffer swapping even when compositor is turned off or blocked. Fixes: https://bugs.launchpad.net/bugs/1308843, https://bugs.launchpad.net/bugs/1308844.

  Approved by PS Jenkins bot, Chris Halse Rogers, Kevin DuBois, Alexandros Frantzis.
------------------------------------------------------------

summary: - Device locks randomly on welcome screen
+ [regression] Device locks randomly on welcome screen
tags: added: regression
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Thank you all, BTW, for the lovely stack traces with line number info. That makes things nice and simple...

Changed in mir:
assignee: Alberto Aguirre (albaguirre) → Mir development team (mir-team)
Dave Morley (davmor2)
description: updated
Changed in mir (Ubuntu):
status: New → Triaged
importance: Undecided → High
tags: added: rtm14
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:mir/devel at revision None, scheduled for release in mir, milestone Unknown

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → In Progress
Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → In Progress
Changed in mir:
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mir - 0.4.1+14.10.20140714-0ubuntu1

---------------
mir (0.4.1+14.10.20140714-0ubuntu1) utopic; urgency=medium

  [ Daniel van Vugt ]
  * Bug fix release 0.4.1 (https://launchpad.net/mir/+milestone/0.4.1) fixes:
    - [regression] Device locks randomly on welcome screen (LP: #1339700)
 -- Ubuntu daily release <email address hidden> Mon, 14 Jul 2014 13:13:37 +0000

Changed in mir (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Marc Feddersen (marc-feddersen) wrote :

FWIW, it seems after OTA updates this issue happens more often.

After running (r119, manta):
  $ ubuntu-device-flash --channel=devel
I had no trouble with this issue lately. :-)

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Yeah image 119 only has Mir 0.4.0 so doesn't have the fix for this yet. Wait a day or so I guess and the mir packages upgrade to 0.4.1.

Changed in mir:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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