1168843 - MOZ_CRASH(SharedMemory not thread-safe) crash on GTK debug builds

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Lee Salzman [:lsalzman]]

The threads on which windows are created, resized, or composited are not the same as the thread which ends up destroying those resources on shutdown. Because SharedMemory and nsShmImage do not use thread-safe reference counting, this always causes a "SharedMemory not thread-safe" crash on shutdown with debug builds using the GTK widget code. This assertion, however, does not trigger in release builds. Note that the shared memory path is only used when Skia is the content rendering backend, as otherwise the Cairo backend will prefer to directly use an Xlib surface instead.

Comment 1

[Lee Salzman [:lsalzman]]

Attachment: Use thread-safe refcounting for shared memory surfaces to avoid shutdown crashes

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8611205 [details] [diff] [review]
Use thread-safe refcounting for shared memory surfaces to avoid shutdown crashes

Review of attachment 8611205 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/nsShmImage.h
@@ +35,4 @@
>  class gfxASurface;
>  
>  class nsShmImage {
> +    NS_INLINE_DECL_THREADSAFE_REFCOUNTING(nsShmImage)

Add a comment about what you know about what threads use this when.

Comment 3

[Lee Salzman [:lsalzman]]

Attachment: Use thread-safe refcounting for shared memory surfaces to avoid shutdown crashes

Added comments referring to bug and documenting that compositor thread is creating shared memory that is destroyed by main thread

Comment 4

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/439ce2fd1fe8

Comment 5

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/439ce2fd1fe8

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/439ce2fd1fe8