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
Commit pushed to master at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/054e85a9d1b3c6acb94edbcd84b503fb96c4df24 Fixes bug 1304849 - More MessageChannel signatures (#3482)
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.
I'll do that, thanks.
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.