On staging armhf (the click test app is armhf) it's still pretty much as
described in comment #15. It is possible to get the "edit comnfig" to
hang, and after the fake stale lock file one will need a second start
attempt so that app really starts.

So this is with Qt 5.6.1 which includes all the patches tried before and
some more. It probably fixes Antti's issue and some others, but not
Michael's test app at least.

Maybe the test case could be submitted upstream stating it'd be nice to
get a fix to 5.6 series? (giving partial assigning to Michael to note
this) There are also no newer commits that seem meaningful to
qlockfile.cpp or qlockfile_unix.cpp, so it should be reproducable on
even dev.

** Changed in: qtbase-opensource-src (Ubuntu)
     Assignee: (unassigned) => Michael Zanetti (mzanetti)

You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qtbase-opensource-src in

  stale lock files freeze apps

Status in Canonical System Image:
Status in qtbase-opensource-src package in Ubuntu:
Status in qtbase-opensource-src package in Ubuntu RTM:

Bug description:
  Debugging why the Notes app would freeze for some people, I found
  there were some stale .lock files around. Those .lock files are
  autocreated by QSettings (with QLockFile) when this file is edited.
  Problem is, that it sometimes seems to happen that the app is
  suspended by our lifecycle and then killed (either by closing from
  spread or OOM killed) and those .lock files stick around. I have
  implemented a workaround in the notes app[1] to clear up those stale
  locks when the app starts app, however, today I ran twice in a row
  into the issue that the very same happened to music app. It would just
  freeze on startup and never come back. Digging around a bit I found
  such a stale lock file on its config file which is created with the
  QML Settings element. This implies that every app using QSettings or
  QML Settings {} are potentially affected. I suspect many more app
  freezes can be traced down to this.

  Now, there is some code in Qt to detect stale lock files [2], however,
  not sure why it doesn't detect those lock files as stale ones and
  decides to wait on them forever though. Probably a bug in the code or
  some of the wrong #ifdefs are triggered for our package builds.


To manage notifications about this bug go to:

Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to