Bugzilla

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #16)
> :mak, are you aware of any recent changes to places or other SQLite consumers that could potentially cause interesting problems here?

No.
Recently Bug 1904967 was reported, that is likely the same as this one?

The messages from FrecencyRecalculator tell the main Places database connection is missing, we're failing to wrap it.
 1. Are we copying over a corrupt database or corrupting it in the process?
 2. is the filesystem locking the file somehow?
 3. Is something just trying to open a connection late on shutdown?

Being opt builds, we can't see the debug warnings to tell if we're failing opening.
I assume something is adding a shutdown blocker on places.sqlite. The main connection is not around, but Andrew found a thread having a handle to places.sqlite, so something was able to opened a connection... A reader connection maybe? We should always be cloning the main connection though.

a. I wonder if there's a problem in how we generate the condprofile, are we copying the database at a safe time (Do we allow enoygh time for Firefox to create the database and fully close)?
b. Can we get a places.sqlite file from one of these failing profiles, to examine it and check if it's corrupt?
c. Can we get crash annotations? I cannot see them in the logs, but I'd like to see the async shutdown metadata.
d. I wonder if tests, in general, should run with `toolkit.asyncshutdown.log` set to true. It may generate some additional noise but may also help with these cases

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #16)
> :mak, are you aware of any recent changes to places or other SQLite consumers that could potentially cause interesting problems here?

No.
Recently Bug 1904967 was reported, that is likely the same as this one?

The messages from FrecencyRecalculator tell the main Places database connection is missing, we're failing to wrap it.
 1. Are we copying over a corrupt database or corrupting it in the process?
 2. is the filesystem locking the file somehow?
 3. Is something just trying to open a connection late on shutdown?

Being opt builds, we can't see the debug warnings to tell if we're failing opening.
I assume something is adding a shutdown blocker on places.sqlite. The main connection is not around, but Andrew found a thread having a handle to places.sqlite, so something was able to opened a connection... A reader connection maybe? We should always be cloning the main connection though.

a. I wonder if there's a problem in how we generate the condprofile, are we copying the database at a safe time (Do we allow enough time for Firefox to create the database and fully close)?
b. Can we get a places.sqlite file from one of these failing profiles, to examine it and check if it's corrupt?
c. Can we get crash annotations? I cannot see them in the logs, but I'd like to see the async shutdown metadata.
d. I wonder if tests, in general, should run with `toolkit.asyncshutdown.log` set to true. It may generate some additional noise but may also help with these cases

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #16)
> :mak, are you aware of any recent changes to places or other SQLite consumers that could potentially cause interesting problems here?

No.
Recently Bug 1904967 was reported, that is likely the same as this one?

The messages from FrecencyRecalculator tell the main Places database connection is missing, we're failing to wrap it. Or alternatively we're trying to wrap it but shutdown already started (These frecencyrecalc may be a red-herring effectively).
 1. Are we copying over a corrupt database or corrupting it in the process?
 2. is the filesystem locking the file somehow?
 3. Is something just trying to open a connection late on shutdown?

Being opt builds, we can't see the debug warnings to tell if we're failing opening.
I assume something is adding a shutdown blocker on places.sqlite. Andrew found a thread having a handle to places.sqlite, so something was able to open a connection... A reader connection maybe?

a. I wonder if there's a problem in how we generate the condprofile, are we copying the database at a safe time (Do we allow enough time for Firefox to create the database and fully close)?
b. Can we get a places.sqlite file from one of these failing profiles, to examine it and check if it's corrupt?
c. Can we get crash annotations? I cannot see them in the logs, but I'd like to see the async shutdown metadata.
d. I wonder if tests, in general, should run with `toolkit.asyncshutdown.log` set to true. It may generate some additional noise but may also help with these cases