1300974 - Race condition can lead to dead lock when enabling LogAlloc

Status: RESOLVED FIXED

(Core :: Memory Allocator, defect)

Comment 1

[Mike Hommey [:glandium]]

Attachment: Work around race condition leading to dead lock on fork when enabling LogAlloc

Comment 2

[Mike Hommey [:glandium]]

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 3

[Nicholas Nethercote [inactive]]

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.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f3aec6a56386
Work around race condition leading to deadlock on fork when enabling LogAlloc. r=njn

Comment 5

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f3aec6a56386