Closed Bug 1173947 Opened 5 years ago Closed 5 years ago
CPOW abort in Send
Get Random Values
Unfortunately this is: 1) aurora only 2) the stacks all suck 3) #1 cpow abort on aurora https://crash-stats.mozilla.com/signature/?product=Firefox&version=40.0a2&date=%3E2015-06-10+23%3A00%3A00&signature=mozalloc_abort%28char+const*+const%29+|+NS_DebugBreak+|+mozilla%3A%3Aipc%3A%3AMessageChannel%3A%3ADebugAbort%28char+const*%2C+int%2C+char+const*%2C+char+const*%2C+bool%29+|+mozilla%3A%3Aipc%3A%3AMessageChannel%3A%3ASend%28IPC%3A%3AMessage*%2C+IPC%3A%3AMessage*%29+|+Pickle%3A%3AWriteBool%28bool%29&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&page=1
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak | mozilla::ipc::MessageChannel::DebugAbort(char const*, int, char const*, char const*, bool) | mozilla::ipc::MessageChannel::Send(IPC::Message*, IPC::Message*) | Pickle::WriteBool(bool)]
David can you provide any insight here? These stacks look off, for example: https://crash-stats.mozilla.com/report/index/44563adb-47ea-4bb2-9b7e-2d6212150611 The Pickle code is in a realloc call, so I don't see how Send ends up on the stack here. Something seems messed up.
Below MessageChannel::Send, I see mozilla::dom::PContentChild::SendGetRandomValues, but I'm having a tough time tracing beyond that. A trick I like to use is to find the crash's counterpart on the opposite bit-ness, and hope that it got better luck with the stacks. For example the x64 crash bp-a9476d85-d34a-44cd-9a7a-0a4a02150611 looks like a plausible match.
(In reply to David Major [:dmajor] from comment #2) > Below MessageChannel::Send, I see > mozilla::dom::PContentChild::SendGetRandomValues, but I'm having a tough > time tracing beyond that. > > A trick I like to use is to find the crash's counterpart on the opposite > bit-ness, and hope that it got better luck with the stacks. For example the > x64 crash bp-a9476d85-d34a-44cd-9a7a-0a4a02150611 looks like a plausible > match. Ah ok, so the crash stack display is messed up. Thanks. So the abort is "can't send sync message of a lesser priority than what's being dispatched" and the caller is SendGetRandomValues.
I'm not having any luck diagnosing these. AFAICT the stacks are all hosed so we really have no idea what these calls are.
The good news, the number of aborts on aurors is small, so this isn't a top crasher.
What happened? I thought we found better stacks pointing to SendGetRandomValues? Is there anything else I can do to help?
(In reply to David Major [:dmajor] from comment #6) > What happened? I thought we found better stacks pointing to > SendGetRandomValues? > > Is there anything else I can do to help? Well you found one in comment 2 but honestly I'm not sure how. I did a search across the x86 stacks looking for a call stack in better shape but didn't find it. So at this point I don't have any data on what this Pickle call might actually be.
I dig through minidump stacks with |dds esp| until I find plausible return addresses. I confirm with |.open -a <address>| that they jump to the next highest frame that I have, otherwise I keep looking. So in bp-44563adb-47ea-4bb2-9b7e-2d6212150611 we had good frames up to MessageChannel::Send, then I found this on the stack: 005219dc 6358a92a xul!mozilla::dom::PContentChild::SendGetRandomValues+0xb9 And the disassembly window for 6358a92a points to the line just after: 6358a925 e8bfb96eff call xul!mozilla::ipc::MessageChannel::Send (62c762e9)
5 years ago
[Tracking Requested - why for this release]: We'd like to get this uplifted when we have a fix
Tracking for 41 because top aurora crasher, keep us posted about the uplift.
This was a simple patch and it looks like we need to fix it soon.
Attachment #8630716 - Flags: review?(mrbkap)
Attachment #8630716 - Flags: review?(mrbkap) → review+
Comment on attachment 8630716 [details] [diff] [review] patch Approval Request Comment [Feature/regressing bug #]: e10s [User impact if declined]: Fixes some crashes. [Describe test coverage new/current, TreeHerder]: Has been on m-c for a while. [Risks and why]: Low risk, we've uplifted a number of similar patches like this, and it's been on nightly for a while. [String/UUID change made/needed]: None
Attachment #8630716 - Flags: approval-mozilla-aurora?
Comment on attachment 8630716 [details] [diff] [review] patch This fix has been in Nightly for a few weeks now. Seems safe to uplift to Aurora.
Attachment #8630716 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.