Comment 15 for bug 1365646

Note that you do not even have to hit Not Now for the crash to occur. You'll get the crash file even while this dialog is still on the screen.

I instrumented systemimage/dbus.py and here's something very interesting:

[systemimage] Sep 09 22:05:19 2014 (13932) Update is downloading
[systemimage] Sep 09 22:05:20 2014 (13932) all files available in /android/cache/recovery
[systemimage] Sep 09 22:05:20 2014 (13932) preparing recovery
[systemimage] Sep 09 22:05:20 2014 (13932) Update downloaded
[systemimage] Sep 09 22:05:20 2014 (13932) release checking lock from _download()
[systemimage] Sep 09 22:05:20 2014 (13932) released!
[systemimage] Sep 09 22:05:20 2014 (13932) -----> DU
[systemimage] Sep 09 22:05:20 2014 (13932) -----> DU
[systemimage] Sep 09 22:05:20 2014 (13932) -----> DU
[systemimage] Sep 09 22:05:20 2014 (13932) Update is downloading
[systemimage] Sep 09 22:05:20 2014 (13932) Update downloaded
[systemimage] Sep 09 22:05:20 2014 (13932) release checking lock from _download()
[systemimage] Sep 09 22:05:20 2014 (13932) Update is downloading
[systemimage] Sep 09 22:05:20 2014 (13932) Update downloaded
[systemimage] Sep 09 22:05:20 2014 (13932) release checking lock from _download()
[systemimage] Sep 09 22:05:20 2014 (13932) Update is downloading
[systemimage] Sep 09 22:05:20 2014 (13932) Update downloaded
[systemimage] Sep 09 22:05:20 2014 (13932) release checking lock from _download()

What this is telling me is that CheckForUpdate is being called, the update is downloaded (since I'm on wifi), and all files are available. It tries to release the checking lock, and it gets released. So far so good.

Next, system-settings calls DownloadUpdate three times in a row! I have no idea why.

Because DownloadUpdate was called without calling CheckForUpdate, when the download is complete (as it is almost immediately because all the files are already available), it will try to release the checking lock, which was never acquired, since it's only acquired in CFU. I need to think on the right fix for this, but it probably involves a downloading lock as well, and perhaps a guard around the checking lock.

Anyway, I think I have enough information to reproduce this in a test case.