1186092 - IPC channel errors should report the parent process's stack

Status: NEW

(Socorro :: General, task)

Description

[(Away)]

ContentParent::KillHard produces paired minidumps of the parent and content processes at the point of an IPC channel error. Today the signature is based on the stack of the content process, but maybe we should use the parent process instead.

Bug 1185726 sent us chasing after phantom "layout crashes" because the content processes just so happened to be doing layout at the time. It was really the stack of the parent process that led us to the source of the error.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

For sync messages, the child process stack is more useful because it shows the stack that led to the call that failed. The parent process stack is always very generic.

Perhaps we could decide how to report based on whether the message was sync or async.

Comment 2

[(Away)]

(In reply to Bill McCloskey (:billm) from comment #1)
> For sync messages, the child process stack is more useful because it shows
> the stack that led to the call that failed. The parent process stack is
> always very generic.
> 
> Perhaps we could decide how to report based on whether the message was sync
> or async.

Thanks for the clarification. I don't speak IPC so I don't really know what I'm talking about here :) I guess we should try to report whichever process is going to be more useful for any given case. If sync/async is a good way to decide that, then sure!

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I don't really know much about how minidump pairing works. Would it be better to make these changes in Gecko or to change Socorro?

Comment 4

[Jim Mathies [:jimm]]

This is handled in ContentParent::KillHard(). We can swap the two stacks, we just have to add a flag to KillHard indicating which process gets 'ownership' of the crash.

Comment 5

[Jim Mathies [:jimm]]

s/stacks/crashreports