Bug 1656987 Comment 13 Edit History

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

I've been unable to reproduce this issue. I've tried stress testing the imagecontainers by minimizing/maximizing which seems to trigger construction and destruction of the instances, but no luck.

Looking at the crash stats it looks like this crash started happening ~73.0.1, but with different callstacks (initially with Webrender), all resulting in a crash in an ImageContainer RtlDeleteCriticalSection crash.

One thing I was wondering about was the potential for a double free or so, but as far as I can see, the memory should have been filled with e5 or e4 if the data was freed and re-used.

I'm not sure how to progress here, one thing we could do is add padding around the mRecursiveMutex and assert on those values to see if it is caused by something writing to the memory at the same offset, but since we haven't been able to reproduce this, it would have to be checked in and verified
I've been unable to reproduce this issue. I've tried stress testing the imagecontainers by minimizing/maximizing which seems to trigger construction and destruction of the instances, but no luck.

Looking at the crash stats it looks like this crash started happening ~73.0.1, but with different callstacks (initially with Webrender), all resulting in a crash in an ImageContainer RtlDeleteCriticalSection crash.

One thing I was wondering about was the potential for a double free or so, but as far as I can see, the memory should have been filled with e5 or e4 if the data was freed and re-used.

I'm not sure how to progress here, one thing we could do is add padding around the mRecursiveMutex and assert on those values to see if it is caused by something writing to the memory at the same offset, but since we haven't been able to reproduce this, it would have to be checked in and verified in the beta population.

Back to Bug 1656987 Comment 13