Bug 1516514 Comment 10 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

The assertion at hand claims that, if a frame has its `hasCachedSavedFrame` bit
set, then it must have a cache entry. This is untrue after we clear the cache
due to compartment mismatch, but the assertion is never reached when the cache
is empty - *or so we had been led to believe*.

Here's the scenario:

- A capture successfully inserts two frames into the cache, setting the
  `hasCachedSavedFrame` bit on each.

- A second capture flushes the cache for a compartment mismatch. Now the cache
  is empty, although both frames still have their bits set.

- A third capture tolerates the spurious `hasCachedSavedFrame` bits, because the
  cache is empty, but then OOMs after inserting only the older frame's entry.

- A fourth capture sees that there is no cache entry for the younger frame, yet
  the cache is not empty, and asserts.
The assertion at hand claims that, if a frame has its `hasCachedSavedFrame` bit set, then it must have a cache entry. This is untrue after we clear the cache due to compartment mismatch, but the assertion is never reached when the cache is empty - *or so we had been led to believe*.

Here's the scenario:

- A capture successfully inserts two frames into the cache, setting the   `hasCachedSavedFrame` bit on each.

- A second capture flushes the cache for a compartment mismatch. Now the cache is empty, although both frames still have their bits set.

- A third capture tolerates the spurious `hasCachedSavedFrame` bits, because the cache is empty, but then OOMs after inserting only the older frame's entry.

- A fourth capture sees that there is no cache entry for the younger frame, yet the cache is not empty, and asserts.

Back to Bug 1516514 Comment 10