Add mozilla::ipc::MessageChannel::AssertWorkerThread and some other IPC methods to the prefix signature list

RESOLVED FIXED

Status

Socorro
General
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: mccr8, Assigned: mccr8)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

2 years ago
mozilla::ipc::MessageChannel::AssertWorkerThread is a release-mode assertion that we're trying to use IPC from the wrong thread. We should add it to the skip list so that these are split out into different signatures depending on what IPDL protocol is hitting the error.

This method is called from various uninteresting methods, so I'll need to add other things. It looks like mozilla::ipc::MessageChannel::Send is there, but mozilla::ipc::MessageChannel::Call is not, and that is showing up in all of these signatures, so I'll add that. I also see mozilla::ipc::MessageChannel::CxxStackFrame::CxxStackFrame in one of these, so I'll add that, too.

Here's an example of a crash with a signature I'm trying to improve: bp-711802ea-35d0-43f5-8aa6-17fc52160922

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
This has now gone into production. Can you verify that it worked on some recently processed crashes. 
Also, if you like (and I think you have the permission) you can go to any existing crash report index page and click the "Reprocess" tab. However some of our server-side caching might last longer than it takes for it to be reprocessed.
(Assignee)

Comment 4

2 years ago
I'll do that, thanks.
(Assignee)

Comment 5

2 years ago
Looks like it works, thanks!

For instance, the report in comment 0 after reprocessing now has the signature: [@ mozilla::ipc::MessageChannel::AssertWorkerThread | mozilla::ipc::MessageChannel::Call | mozilla::plugins::PPluginModuleChild::CallGetKeyState ]
You need to log in before you can comment on or make changes to this bug.