1706298 - AsyncShutdownTimeout | places.sqlite related to expiring orphan icons

Status: NEW

(Toolkit :: Places, defect, P5)

Description

[Jens Stutte [:jstutte]]

From bug 1588498, comment 17

Firefox 87.0 Crash Report [@ AsyncShutdownTimeout | places.sqlite#1: waiting for clients | Transaction (114),places.sqlite#1: PlacesExpiration.jsm: expire (115) ]

This is an interesting signature, we should file a separate bug for it, since it looks like many of these timeouts are related to removing orphan icons, there may be a common cause. I don't expect that to be related to QuotaManager or indexedDB anyway.

Apparently this is hanging on "DELETE FROM moz_pages_w_icons WHERE page_url_hash NOT IN (SELECT url_hash FROM moz_places) OR id NOT IN (SELECT DISTINCT page_id FROM moz_icons_to_pages)"
There may be various reasons:

there is some database corruption
there is an unknown deadlock related to ATTACHed databases
removing orphan icons is just very slow under certain circumstances

Did we go through the usual troubleshooting steps?
First thing i'd suggest to run Places Database Integrity check from about:support, and post the resulting log of that here or in the newly filed bug.
Then check if things improved after a restart.
Another interesting experiment would be to pretty much drop favicons, so go to the profile folder when Firefox is closed and move favicons.sqlite (and favicons.sqlite-wal) elsewhere. Launching firefox should generate a new one, and potentially resolve any unexpected perf issue with it, but will also lose all the favicons on bookmarks until you revisit them. You can always restore the previously moved file anyway, after the experiment. If that solves the problem, I may be interested into getting more statistics about that db.

Comment 1

[Jens Stutte [:jstutte]]

Unfortunately the signature is not stable and the signature field here does not support partial signatures, AFAIU.

Comment 2

[Marco Bonardo [:mak]]

We landed a mitigation in 109, what's left is to check if the crash volume reduces with time, for that it may be a bit early though.

Comment 3

[Marco Bonardo [:mak]]

Most of the issues should be resolved, I completely removed one of the 2 queries from shutdown, I could still find a report related to the other one, but we can't do miracles there, some system may just be too slow.
I think we can, at least, reduce the priority now.

Comment 4

[Mark Banner (:standard8)]

There doesn't seem to be many of these crashes left. Probably no more than ~ 11 crashes per version. Most likely very slow systems.

Dropping to P5 for now as there isn't much worth doing on this.

Comment 5

[Jens Stutte [:jstutte]]

Most of the volume seems to come from ESR 128 these days.

But there is some consistent volume also for current release versions. The signatures continue to be noisy with extra info that might be helpful for debugging.