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.
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.