1607739 - Retake thread locks at a consistent point

Status: RESOLVED FIXED

(Core Graveyard :: Web Replay, enhancement)

Description

[Brian Hackett [Laid off!]]

Before forking, all non-main threads need to release the locks they have acquired: the forked process will only have its main thread, and any threads it respawns will not be able to retake those locks, which are still considered to be held. After the fork, both processes need their threads to retake the locks, but the way this is done is slightly different for the original process and the forked process. This should be done consistently, to make the code easier to follow but particularly to help diagnose a major source of crashes on treeherder. When the forked process retakes its locks we are getting some failures where pthread_mutex_lock returns EINVAL, suggesting that during the fork the mutex was destroyed. I suspect this is because some destructor associated with one of the non-main threads is running in the forked process and destroying the mutex. It's hard to be sure because there isn't any way to tell which locks are being reacquired in the forked process, but by using the same strategy for retaking locks as we have in the original process, the reacquisition will happen after the thread's stack has been restored. Crash reports will include those stacks and we should get some clues about which locks are causing the problem.

Comment 1

[Brian Hackett [Laid off!]]

Attachment: Bug 1607739 - Retake thread locks at a consistent point, r=jlast.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c2b3e2651a6a
Retake thread locks at a consistent point, r=jlast.

Comment 3

[Andreea Pavel [:apavel]]

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