Closed Bug 1168843 Opened 5 years ago Closed 5 years ago

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

Categories

(Core :: Widget: Gtk, defect)

Unspecified
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
firefox41 --- fixed

People

(Reporter: lsalzman, Assigned: lsalzman)

Details

Attachments

(1 file, 1 obsolete file)

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 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.
Attachment #8611205 - Flags: review?(jmuizelaar) → review+
Added comments referring to bug and documenting that compositor thread is creating shared memory that is destroyed by main thread
Attachment #8611205 - Attachment is obsolete: true
Attachment #8611237 - Flags: review?(jmuizelaar)
Attachment #8611237 - Flags: review?(jmuizelaar) → review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/439ce2fd1fe8
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
You need to log in before you can comment on or make changes to this bug.