Corrupt QML cache - Apps Fail to start

Thanks for your report. Setting to confirmed, another user reported a similar issue on the ubuntu-phone mailing list with the dialler app and clearing the cache manually allowed the app to start.

I'll make a suggestion here to get some comments, but it seems to me there's 2 threads to chase
1) actually figure out why the cache is getting corrupted
2) create some detection as part of the launch (ual? or qtmir?) to determine if there are issues and then delete the cache & make a second launch attempt

QtMir has code that should delete the cache, if the app stops unexpectedly (i.e. probably crashed).

The QML cache system also does a CRC check on the cache file, to check it before using it. So the file being munged unexpectedly should not be a fatal condition.

Instead, if the app is itself corrupting the cache somehow, it would be good to know why. Certainly if the app crashes on startup while reading its cache, QtMir should delete the cache so the next execution will succeed.

Would be worth verifying this is functioning as expected.

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

I just duped over a number of these reports, clearly we are not properly removing the cache when the app fails to start.

It's also possible that u-a-l doesn't give qtmir notice that the app indeed failed to start. I don't think we're clearing the cache on *any* crash, just on startup - maybe we need to be more aggressive with that.

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

Wouldn't clearing the cache at every crash just hide the problem under the carpet?

Well, if we get a report of the crash through errors.u.c, maybe not? Better for the app to start next time or not?

That's assuming the QML cache is at fault in the first place - if the app just crashes on its own accord, clearing the cache or not doesn't really matter.

Thing is, in case the cache is corrupt, but the app is dynamic - it will start but then crash after the user opened some new page with a new qml file - and there's no way other than upgrading the app that this will get better.

My fear is that by cleaning the cache every crash we're just postponing assigning someone to actually fixing the QML cache problems :/

(of course, as you say, it may be that it's not the QML cache at fault, but we know that there's something wrong going on there almost for sure, right? so many bug reports with the same fix)

Sure, I'm not saying there isn't a problem in the cache, just saying the user doesn't care - and we should do everything in our power to get the app to start again. IMO that's orthogonal to the fact that we need to investigate how the QML cache gets corrupted.

of course!

The UAL signal for failing on starting would only be before the process starts executing. So basically everything up to passing off to the Exec line in the desktop file. After that we pretty much lose track of the process. So I don't think that UAL can really be used to tell whether the app failed because of a corrupt cache or not since it wouldn't be known until the Qt parts start executing.

Thinking about this more, we can get the status code that is returned by the utility. If we wanted to return a custom status code for "delete the QML cache" we could do that.