Scopes freeze after few times slide on Bq 4.5

[lotuspsychje]

BQ 4.5 Ubuntu-touch OTA7 (Ubuntu 15.04 r26)

After a few slides on the scopes, it freezes the scopes in the middle of 2 scopes
unity left bar can still be moved, but when launching apps from the left bar
nothing happens to the freezed scopes screen, only rebooting the phone fixes it.

when i remove some scopes from favorites it freezes on other scopes

Let me know wich logs i can attach to this bug to make debug easier.

[Albert Astals Cid (aacid)]

Some questions:
 * Can you reproduce this problem or did it just happen once?
 * Were you just swiping left/right or doing something else that you think could have caused the crash?
 * Do you have "App crashes and errors" enabled in System Settings->Security & Privacy->Diagnostics?
 * Can you give us a list and order of the scopes you have favorited?

[lotuspsychje (lotuspsychje)]

@ #2 Albert:

*Yes i can reproduce the freeze every time i swipe scopes, the first few slide ok, the further i come the more chance of freeze

*Im just swiping scopes, no other apps running while i reproduce

*I do have app crashes and errors enabled

*scopes list favorites from left to right: apps scope|de standaard scope|softpedia linux scope|uapp explorer scope|500px scope|
engadget scope|soundcloud scope|mixcloud scope

when i disable the freezing scopes, it freezes on other scopes

[Albert Astals Cid (aacid)]

Could reproduce it here with the scopes lotuspsychje mentions.

The full backtrace of the threads can be found at http://paste.ubuntu.com/13527117/

Seems like something is getting stuck in the scopes side, adding a few more projects

[Albert Astals Cid (aacid)]

Seems mixcloud is the one causing the problem, as a temporary workaround you can remove it, we'll work on figuring out why it happens.

[Paweł Stołowski (stolowski)]

Ok, this scope locks the dash up even when not favorited and just opened via Manage Dash. Moreover, it even locks up a commandline scopes-client (for libunity-scopes-cli package):

$ scopes-client com.ubuntu.developer.boghison.mixcloud_mixcloudscope ""

It looks like we are not as resistant to misbehaving scopes as we should be. The scopes-client re-implements finished() method of SearchListener, but it's not triggered with this scope (this method should eventually receive an error I think).

[Paweł Stołowski (stolowski)]

Ok, mixcloud scope seems to be released in completely broken state, its ini file has this:

ScopeRunner=./qtc_device_debughelper.py scope com.ubuntu.developer.boghison.mixcloud_mixcloudscope /usr/lib/arm-linux-gnueabihf/unity-scopes/scoperunner '' %S

So it's not even really running in the system. Scopesregistry logfile has this error (the extra debug output is from the qtc_device_debughelper.py shipped by mixcloud scope):

Debug-helper> Setting up environment
Debug-helper> TmpDir: /home/phablet/.local/share/unity-scopes/leaf-net/com.ubuntu.developer.boghison.mixcloud/
Debug-helper> AppId: com.ubuntu.developer.boghison.mixcloud_mixcloudscope
Debug-helper> Environment: confined
Debug-helper> Environment initialized, starting the application
Debug-helper> Executing /usr/lib/arm-linux-gnueabihf/unity-scopes/scoperunner['/usr/lib/arm-linux-gnueabihf/unity-scopes/scoperunner', '/home/phablet/.local/share/unity-scopes//com.ubuntu.developer.boghison.mixcloud_mixcloudscope_0.2', '/home/phablet/.local/share/unity-scopes//com.ubuntu.developer.boghison.mixcloud_mixcloudscope_0.2/com.ubuntu.developer.boghison.mixcloud_mixcloudscope.ini']
[2015-11-27 15:32:31.902474] ERROR: com.ubuntu.developer.boghison.mixcloud_mixcloudscope: unity::scopes::ConfigException: Cannot instantiate run time for com.ubuntu.developer.boghison.mixcloud_mixcloudscope, config file: /home/phablet/.local/share/unity-scopes//com.ubuntu.developer.boghison.mixcloud_mixcloudscope_0.2:
    unity::scopes::ConfigException: invalid config file name: "/home/phablet/.local/share/unity-scopes//com.ubuntu.developer.boghison.mixcloud_mixcloudscope_0.2": missing .ini extension
scoperunner: unity::scopes::ConfigException: Cannot instantiate run time for com.ubuntu.developer.boghison.mixcloud_mixcloudscope, config file: /home/phablet/.local/share/unity-scopes//com.ubuntu.developer.boghison.mixcloud_mixcloudscope_0.2:
    unity::scopes::ConfigException: invalid config file name: "/home/phablet/.local/share/unity-scopes//com.ubuntu.developer.boghison.mixcloud_mixcloudscope_0.2": missing .ini extension

Now, it seems that somehow the errors don't make it to the client and it's stuck forever waiting for IPC.

[Michi Henning (michihenning)]

OK, so the root cause is the broken scope config. But we shouldn't misbehave in this way just because the scope has a broken config.

I'll look at this on Monday.

[Michi Henning (michihenning)]

Hmmm... I just tried to reproduce, but cannot. I modified the demo scope-A .ini file to point at a script:

ScopeRunner = /tmp/tryit

I've tried with the script immediately exiting with status 1, with status 0, and with the script hanging (by sleeping). Trace in the script verifies that the registry calls it correctly.

If the script exits, the client, receives a MiddlewareException from search() saying that the scope failed to start correctly after four seconds.

If the script hangs, the client gets the same exception from search, but after 8 seconds (because we do the locate() behind the scenes).

All this is as expected. Pawel, what did you do to make the demo client hang?

At any rate, I don't think there is any obvious problem with scopes-api. The behavior is as expected. Maybe the shell or the client you used do not handle the exception from search() correctly? Note that it is not possible to trigger the finished() callback if the scope never gets off the ground in the first place...

[Paweł Stołowski (stolowski)]

Looking at ScopeImpl.cpp I'm not sure how search can throw (btw, Scope.h docstrings don't mention throwing an exception). As far as I understand the code, search catches all exceptions and just calls ro->finished(CompletionDetails(CompletionDetails::Error, e.what())) on error. But this doesn't happen with our case as far as I can tell (our listener implementes finished() and prints a message). Also, shell code does have try-catch around search & logs an error, but I didn't see it in the logs - the last message we have in shell logs is "Dispatching search: <scope id>" and it gets stuck there.

I made scopes-client tool hang by just executing search against the misbehaving scope with it:
$ scopes-client com.ubuntu.developer.boghison.mixcloud_mixcloudscope ""

[Paweł Stołowski (stolowski)]

Ok, the real problem is this scope has debug mode enabled in the ini file:
ScopeRunner=./qtc_device_debughelper.py scope com.ubuntu.developer.boghison.mixcloud_mixcloudscope /usr/lib/arm-linux-gnueabihf/unity-scopes/scoperunner '' %S
DebugMode=true

which pretty much disables all the timeouts we have in the middleware (so that scopes can be debugged with SDK & gdb, client doesn't throw after scope execution is paused). Scopes should never be released in such state to the store (store should prevent this IMO). It would also be nice if we could deal with it somehow.

[Marcus Tomlinson (marcustomlinson)]

Seems click-reviewers-tools needs to be updated to fail if DebugMode appears in the ini. I'll submit a fix for this soon.

[Jamie Strandboge (jdstrand)]

FYI, I'm fine with the extra check but debugmode should've already triggered the 'unknown' checks. Indeed it does:

$ click-review /var/www/html/store/all/com.ubuntu.developer.boghison.mixcloud_0.2_armhf.click
Errors
------
 - lint:framework
 'ubuntu-sdk-14.10-dev2' is obsolete. Please use a newer framework
 http://askubuntu.com/questions/460512/what-framework-should-i-use-in-my-manifest-file
 - security:policy_groups_safe:mixcloudscope:debug
 (REJECT) reserved policy group 'debug': not for production use
 - security:policy_groups_scopes:mixcloudscope.apparmor
 found inappropriate policy groups: debug
Warnings
--------
 - scope:ini_scope_unknown_fields:mixcloudscope
 Unknown field in 'mixcloudscope/com.ubuntu.developer.boghison.mixcloud_mixcloudscope.ini': debugmode
/var/www/html/store/all/com.ubuntu.developer.boghison.mixcloud_0.2_armhf.click: FAIL

So, the store did its job-- someone manually accepted this into the store.

[Paweł Stołowski (stolowski)]

I've asked to unpublish this scope from the store for now, fgallina took care of that.

[Launchpad Janitor (janitor)]

This bug was fixed in the package click-reviewers-tools - 0.35

---------------
click-reviewers-tools (0.35) xenial; urgency=medium

  [ Jamie Strandboge ]
  * clickreviews/cr_systemd.py:
    - add checks for listen-stream, socket, socket-user and socket-group
    - remove vendor checks with bus-name (LP: #1510522)
  * clickreviews/cr_security.py:
    - make sure that the generated profile name is under the current 253
      character maximum. This might have to be adjusted after the AppArmor
      stacking work is completed (LP: #1499544)
    - adjust for xenial snappy defaulting to using 'network-client' instead
      of 'networking'
    - use 'NEEDS REVIEW' instead of 'MANUAL REVIEW'
  * clickreviews/cr_lint.py:
    - check if package ships .click directory
    - add a few more vcs files
    - remove vendor-specific checks. 'vendor' is still allowed for
      compatibility with older snappy versions, but no formatting checks are
      performed (LP: #1510522)
    - 'Maintainer' checks in the click manifest should only be done with click
      packages (LP: #1510522)
    - don't prompt manual review when find .excludes file
    - add kernel and os as valid snap types
    - remove package filename checks. They were meaningless and hard to
      maintain
    - sort unknown snappy yaml keys
    - use 'NEEDS REVIEW' instead of 'MANUAL REVIEW'
  * clickreviews/cr_common.py:
    - add valid yaml keys for kernel snaps
    - add a couple more mime types for detecting binaries (useful for arm
      kernels)
  * update data/apparmor-easyprof-ubuntu.json for 16.04 policy
  * Makefile: add json syntax check
  * several changes for squashfs snaps that won't have a click manifest, etc.
    Importantly, this means that only package.yaml is looked at and a lot of
    click specific tests can be skipped
    - cr_common.py:
      + rename a few variable to not be click specific
      + add self.pkgfmt
      + adjust __init__() to conditionally use package.yaml on squashfs,
        otherwise click manifest
      + make click data structure initialization conditional on if click
        or not (eg, don't run hooks code on squashfs images)
    - adjust clickreviews/cr_* to conditionally run certain click-only tests
      on click packages
    - adjust architecture checks to use self.pkg_arch and rename
      control_architecture_specified_needed as architecture_specified_needed
    - cr_security.py:
      + revamp to use package.yaml on non-click instead of now nonexistent
        security manifest
      + update push-helper template test to not make hooks specific
      + network-client should not be allowed with push helpers either
      + conditionally look for INSTALL_DIR on 16.04 systems in security-policy
      + adjust security-override checks on 16.04 to follow 16.04 yaml
      + make click manifest checks conditional on if click
    - cr_tests.py: mock _pkgfmt_type(), _pkgfmt_version() and _is_squashfs()

  [ Michael Nelson ]
  * add support for non-mocked tests

  [ Michael Vogt ]
  * add support for squashfs snaps (currently will trigger manual review)

  [ Daniel Holbach ]
  * Pass absolute path of click or snap file - that way it's safe even if we
...