Closed Bug 1220113 Opened 5 years ago Closed 2 years ago

Evaluate asserting once in case of unclean shutdown

Categories

(Toolkit :: Storage, defect)

defect
Not set

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox45 --- affected

People

(Reporter: mak, Unassigned)

References

Details

currently the only thing we do is firing a bunch of warnings about unfinalized statements, but that gets unnoticed until someone actually complains in a bug.

We may assert too.
The risk is:
1. increase random failures
2. annoy developers

we can control 1, we can do multiple Try runs with the assertion and check how we are.
2 should then happen rarely, since we have a bunch of tests, and in some cases it will be a positive thing (especially for add-on developers to properly shutdown their connections).

I'd start with 1, and see how bad is the impact, that should give us an idea of how much we may hit the assertion in the wild.
Does assert in this case mean crash/abort in:
A) Debug builds / test builds only?
B) Dev edition / nightly builds only?
C) All production builds.

If we're talking 'C', then it seems likely that there are extensions out there that could make this shoot to the top of crash-stats and really frustrate some users.

If a goal is to keep the in-tree consumers clean, then "A" seems good enough for that.

If a goal is to find out about mis-use of mozStorage/SQLite.jsm by extensions in the field, then maybe telemetry or the Firefox Health Report mechanism is a better use-case since that can happen without crashing?  The only trick there might be that the finalization warnings would likely happen at shutdown which might be too late to report such things.  (But maybe those mechanisms thought of that and have helpers?)
I don't know of any helper, but a few mechanisms that collect their data too late write it to disk, to be able to submit it to Telemetry on the next launch.
In the last years we added MOZ_ASSERTS to shutdown, also thanks to add-ons not being able anymore to hook directly into Storage. So this is likely wfm.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.