This bug was filed from the Socorro interface and is report bp-2a72f9aa-bb7c-42f5-ac45-0f7880170729. ============================================================= There are 132 crashes in release 54.0.1 where mp4_demuxer is involved in the backtrace [1]. :alfredo, could you investigate ? [1] https://crash-stats.mozilla.com/search/?signature=%3Dcore%3A%3Aresult%3A%3Aunwrap_failed%3CT%3E%20%7C%20std%3A%3Acollections%3A%3Ahash%3A%3Amap%3A%3A%7B%7Bimpl%7D%7D%3A%3Anew%3A%3AKEYS%3A%3A__init&proto_signature=~mp4_demuxer&product=Firefox&date=%3E%3D2017-07-24T16%3A52%3A00.000Z&date=%3C2017-07-31T16%3A52%3A00.000Z&_sort=-date&_facets=signature&_facets=version&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-version

It looks like binding problem between C++/rust. Hi Ralph, any idea about this? [1] https://crash-stats.mozilla.com/report/index/07f83597-27c8-443f-b13f-2d1bf0170727

So the crash starts inside mp4parse_new() when it calls `(*io).read.is_none()`. `*io` is an mp4parse_io struct, whose io member is an Option<Fn> which turns into a nullable function pointer over ffi. The next funtion on the stack is `std::collections::hash::map::{{impl}}::new::KEYS::__init` citing C:/projects/rust/src/libstd/thread/local.rs:169 which in rust 1.16.0 is the `__init` method generated by the `__thread_local_inner` macro. If the function name an MOZ_CRASH_REASON are correct, that suggests the actual failure is rust/src/libstd/collections/hash/map.rs:2143 where the HashMap's RandomState checks the result of rand::OsRng::new() before stashing thread-local key ordering state. This calls sys::rand::OsRng which in rust/src/libstd/sys/windows/rand.rs:26 calls CryptAcquireContextA and returns success for failure based on that. Now, I don't know why CryptAcquireContextA would fail here, but more importantly, I don't know why (*io).read.is_none() would initialize a HashMap. `is_none()` is just a simple match statement. So heap (or stack) corruption seems likely. Without Steps to Reproduce it's not obvious to me how to proceed. David, do you have any ideas what might be going on?

(In reply to Ralph Giles (:rillian) | needinfo me from comment #2) > Now, I don't know why CryptAcquireContextA would fail here, but more > importantly, I don't know why (*io).read.is_none() would initialize a > HashMap. `is_none()` is just a simple match statement. So heap (or stack) > corruption seems likely. Without Steps to Reproduce it's not obvious to me > how to proceed. I disassembled mp4parse_new on a recent beta55 build, and I see three `je` tests that lead to a quick return (presumably corresponding to `io.is_null()` and `(*io).userdata.is_null()` and `(*io).read.is_none()`), followed by some HashMap work. I'm guessing that the debug info isn't matched up exactly to the right line, and in fact the reported crash was a few lines later in one of the `HashMap::new()` calls: https://hg.mozilla.org/releases/mozilla-beta/annotate/e5f14b9ae6c4/media/libstagefright/binding/mp4parse_capi/src/lib.rs#l286 If you ignore the line mismatch and assume we came via HashMap::new(), does it make any better sense?

Mass change P1->P2 to align with new Mozilla triage process

No new crashes reported over 1 month, so close this bug.