1301665 - Crash by accessing uninitialized library mapping

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Eugen Sawin [:esawin]]

We have race conditions when trying to access the library mapping info during startup via lib_mapping or getLibraryMapping before it has been allocated and initialized.

Bug 689178 will have the proper fix, but let's prevent the crashes for the time being.

Comment 1

[Eugen Sawin [:esawin]]

Attachment: 0001-Bug-1301665-1.1-Statically-initialize-lib-mapping-ar.patch

Static lifetime variables are zero-initialized. Is there a reason not to have the mapping in the data segment? Alternatively, we can allocate it in getLibraryMapping and switch all call sites to us it (including non-const access).

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5011ecc31611
[1.1] Statically initialize lib mapping array. r=glandium

Comment 3

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/5011ecc31611

Comment 4

[Eugen Sawin [:esawin]]

Comment on attachment 8789759 [details] [diff] [review]
0001-Bug-1301665-1.1-Statically-initialize-lib-mapping-ar.patch

Approval Request Comment
[Feature/regressing bug #]: N/A
[User impact if declined]: Potential startup crashes
[Describe test coverage new/current, TreeHerder]: Nightly and Aurora
[Risks and why]: Minimal, simple code change that makes sure a structure is initialized before use
[String/UUID change made/needed]: None

Comment 5

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8789759 [details] [diff] [review]
0001-Bug-1301665-1.1-Statically-initialize-lib-mapping-ar.patch

Crash fix, it has stabilized on 51 for ~3 weeks, Beta50+

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/05626081c674