Bug 1679368 Comment 2 Edit History

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

Original comment by
on 
It looks like `EBUSY` is indeed the cause here. Have a look at this crash: https://crash-stats.mozilla.org/report/index/d590969d-36e5-4411-9437-446e80201126

Thread 13 is in this call to [`RenderThread::UpdateAndRender()`](https://searchfox.org/mozilla-central/rev/f081504642a115cb8236bea4d8250e5cb0f39b02/gfx/webrender_bindings/RenderThread.cpp#537-538). Thread 22 is also reacting to some compositor IPC call. I noticed that [nsChildView::PreRender()](https://searchfox.org/mozilla-central/rev/f081504642a115cb8236bea4d8250e5cb0f39b02/widget/cocoa/nsChildView.mm#1705) acquires the affected lock and is called by compositor code.

Markus is it possible that we're invoking `nsChildView`'s destructor in between a call to `nsChildView::PreRender()` and `nsChildView::PostRender()`? That would explain why `pthread_mutex_destroy()` is failing.
Revision 1 by
on 
It looks like `EBUSY` is indeed the cause here. Have a look at this crash: https://crash-stats.mozilla.org/report/index/d590969d-36e5-4411-9437-446e80201126

Thread 13 is in this call to [`RenderThread::UpdateAndRender()`](https://searchfox.org/mozilla-central/rev/f081504642a115cb8236bea4d8250e5cb0f39b02/gfx/webrender_bindings/RenderThread.cpp#537-538). Thread 22 is also reacting to some compositor IPC call. I noticed that [`nsChildView::PreRender()`](https://searchfox.org/mozilla-central/rev/f081504642a115cb8236bea4d8250e5cb0f39b02/widget/cocoa/nsChildView.mm#1705) acquires the affected lock and is called by compositor code.

Markus is it possible that we're invoking `nsChildView`'s destructor in between a call to `nsChildView::PreRender()` and `nsChildView::PostRender()`? That would explain why `pthread_mutex_destroy()` is failing.

Back to Bug 1679368 Comment 2