Closed Bug 1301665 Opened 3 years ago Closed 3 years ago
Crash by accessing uninitialized library mapping
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.
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).
Attachment #8789759 - Flags: review?(mh+mozilla)
Attachment #8789759 - Flags: review?(mh+mozilla) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/5011ecc31611 [1.1] Statically initialize lib mapping array. r=glandium
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
Attachment #8789759 - Flags: approval-mozilla-beta?
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+
Attachment #8789759 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.