Closed Bug 1300974 Opened 3 years ago Closed 3 years ago

Race condition can lead to dead lock when enabling LogAlloc

Categories

(Core :: Memory Allocator, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox51 --- fixed

People

(Reporter: glandium, Assigned: glandium)

Details

Attachments

(1 file)

No description provided.
Note, back when LogAlloc was written, this was less of a problem, because we weren't forking much. But now, with e10s, and the process forking to check GLX, this actually happens a lot more often. Often enough that you don't get a working browser most of the time when enabling LogAlloc without the patch.
Comment on attachment 8788752 [details] [diff] [review]
Work around race condition leading to dead lock on fork when enabling LogAlloc

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

Nit: it's "deadlock" rather than "dead lock".

::: memory/replace/logalloc/LogAlloc.cpp
@@ +95,5 @@
> +   *   - consequently, thread B holds our lock
> +   *   - thread B then proceeds to call the real allocator's malloc, and
> +   *     waits for the real allocator's lock, which thread A holds.
> +   *   - libc calls our prefork, so thread A waits for our lock, which
> +   *     thread B holds.

Nit: inconsistent use of '.' at end of list items.
Attachment #8788752 - Flags: review?(n.nethercote) → review+
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f3aec6a56386
Work around race condition leading to deadlock on fork when enabling LogAlloc. r=njn
https://hg.mozilla.org/mozilla-central/rev/f3aec6a56386
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.