Closed Bug 1173947 Opened 5 years ago Closed 5 years ago

CPOW abort in SendGetRandomValues

Categories

(Core :: IPC, defect)

x86_64
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla42
Tracking Status
e10s m8+ ---
firefox41 + fixed
firefox42 --- fixed

People

(Reporter: jimm, Assigned: billm)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

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.
Flags: needinfo?(dmajor)
Keywords: crash
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.
Flags: needinfo?(dmajor)
(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.
Flags: needinfo?(jmathies)
I'm not having any luck diagnosing these. AFAICT the stacks are all hosed so we really have no idea what these calls are.
Flags: needinfo?(jmathies)
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)
Summary: CPOW abort in Pickle::WriteBool(bool) → CPOW abort in SendGetRandomValues
Assignee: nobody → bobbyholley
reflagging, top aurora crasher.
[Tracking Requested - why for this release]: We'd like to get this uplifted when we have a fix
Assignee: bobbyholley → wmccloskey
Tracking for 41 because top aurora crasher, keep us posted about the uplift.
Attached patch patchSplinter Review
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+
https://hg.mozilla.org/mozilla-central/rev/c88fbfdc2af4
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
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.