Crash in IPCError-browser | (msgtype=0x580009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized

RESOLVED FIXED

Status

()

P2
critical
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: jimm, Assigned: tbsaunde)

Tracking

(Blocks: 1 bug)

42 Branch
All
Windows
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(e10s+, firefox49 affected, firefox50 affected)

Details

(Whiteboard: KillHard, aes+, crash signature)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
This is an outstanding a11y KillHard abort. Looks like the api must be async since the failures happen in during a random mix of unrelated e10s api calls.

Bug 1116884 KillHard child signature breakdown:
----------------------------------------------------
23	51.1%	SendRpcMessage(..)
7	15.6%	mozilla::plugins::PPluginWidgetChild::SendGetNativePluginPort(..)
3	6.7%	SendSyncMessage(..)
3	6.7%	mozilla::dom::PContentChild::SendGetBlocklistState(..)
2	4.4%	mozilla::net::PCookieServiceChild::SendGetCookieString(..)
2	4.4%	mozilla::layers::PLayerTransactionChild::SendUpdate(nsTArray<mozilla::layers::Edit> const &,unsigned __int64 const &,mozilla::layers::TargetConfig const &,nsTArray<mozilla::layers::PluginWindowData> const &,bool const &,bool const &,unsigned int const &,bool const &,mozilla::TimeStamp const &,nsTArray<mozilla::layers::EditReply> *)
2	4.4%	mozilla::dom::PScreenManagerChild::SendScreenForBrowser(mozilla::dom::IdType<mozilla::dom::TabParent> const &,mozilla::dom::ScreenDetails *,bool *)
1	2.2%	mozilla::dom::PContentChild::SendClipboardHasType(nsTArray<nsCString> const &,int const &,bool *)
1	2.2%	mozilla::layers::PLayerTransactionChild::SendUpdate(nsTArray<mozilla::layers::Edit> const&, unsigned long const&, mozilla::layers::TargetConfig const&, nsTArray<mozilla::layers::PluginWindowData> const&, bool const&, bool const&, unsigned int const&, bool const&, mozilla::TimeStamp const&, nsTArray<mozilla::layers::EditReply>*)
1	2.2%	mozilla::dom::PBrowserChild::SendGetInputContext(..)

IPC error breakdown per KillHard signature:
----------------------------------------------------
SendRpcMessage(..):
  3 - '(msgtype=0x3C0002,name=???) Route error: message sent to unknown actor ID'
  3 - '(msgtype=0x200012,name=???) Message not allowed: cannot be sent/recvd in this state'
  6 - 'HangMonitor'
  8 - '(msgtype=0x200004,name=PBrowser::Msg_PDocAccessibleConstructor) Processing error: message was deserialized, but the handler returned false (indicating failure)'
  4 - '(msgtype=0x4A0008,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized, but the handler returned false (indicating failure)'

mozilla::plugins::PPluginWidgetChild::SendGetNativePluginPort(..):
  1 - '(msgtype=0xA20006,name=???) Message not allowed: cannot be sent/recvd in this state'
  7 - '(msgtype=0x4A0008,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized, but the handler returned false (indicating failure)'

SendSyncMessage(..):
  3 - 'HangMonitor'
  1 - '(msgtype=0x4A0008,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized, but the handler returned false (indicating failure)'

mozilla::dom::PContentChild::SendGetBlocklistState(..):
  4 - '(msgtype=0x3A004E,name=PContent::Msg_GetBlocklistState) Processing error: message was deserialized, but the handler returned false (indicating failure)'

mozilla::net::PCookieServiceChild::SendGetCookieString(..):
  2 - '(msgtype=0x3C0002,name=???) Route error: message sent to unknown actor ID'
  1 - '(msgtype=0x4A0008,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized, but the handler returned false (indicating failure)'

mozilla::layers::PLayerTransactionChild::SendUpdate(nsTArray<mozilla::layers::Edit> const &,unsigned __int64 const &,mozilla::layers::TargetConfig const &,nsTArray<mozilla::layers::PluginWindowData> const &,bool const &,bool const &,unsigned int const &,bool const &,mozilla::TimeStamp const &,nsTArray<mozilla::layers::EditReply> *):
  3 - '(msgtype=0x4A0008,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized, but the handler returned false (indicating failure)'

mozilla::dom::PScreenManagerChild::SendScreenForBrowser(mozilla::dom::IdType<mozilla::dom::TabParent> const &,mozilla::dom::ScreenDetails *,bool *):
  2 - 'HangMonitor'
  1 - '(msgtype=0x4A0008,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized, but the handler returned false (indicating failure)'

mozilla::dom::PContentChild::SendClipboardHasType(nsTArray<nsCString> const &,int const &,bool *):
  2 - '(msgtype=0x3A00A2,name=???) Message not allowed: cannot be sent/recvd in this state'

mozilla::layers::PLayerTransactionChild::SendUpdate(nsTArray<mozilla::layers::Edit> const&, unsigned long const&, mozilla::layers::TargetConfig const&, nsTArray<mozilla::layers::PluginWindowData> const&, bool const&, bool const&, unsigned int const&, bool const&, mozilla::TimeStamp const&, nsTArray<mozilla::layers::EditReply>*):
  2 - '(msgtype=0x4A0008,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized, but the handler returned false (indicating failure)'

mozilla::dom::PBrowserChild::SendGetInputContext(..):
  2 - '(msgtype=0x4A0008,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized, but the handler returned false (indicating failure)'
(Reporter)

Updated

3 years ago
Version: 41 Branch → Trunk
tracking-e10s: ? → +
(Assignee)

Comment 1

3 years ago
see my last comment in bug 1185726 I guess we should just change it to assert and return true until we find the bug in the child.
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1192300
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1192528
Assignee: nobody → tbsaunde+mozbugs
(Assignee)

Comment 4

3 years ago
Created attachment 8648170 [details] [diff] [review]
only coalesce reorder events when a previous one for the same target is obsolete

Having one reorder event that superseeds another does not mean that the
dependant mutation events for the first reorder are obsolete.
Attachment #8648170 - Flags: review?(surkov.alexander)
Comment on attachment 8648170 [details] [diff] [review]
only coalesce reorder events when a previous one for the same target is obsolete

Review of attachment 8648170 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with comments addressed

::: accessible/tests/mochitest/treeupdate/test_bug1189277.html
@@ +21,5 @@
> +      this.eventSeq = [];
> +      this.containerNode = getNode("outerDiv");
> +
> +      this.eventSeq.push(new invokerChecker(EVENT_REORDER, this.containerNode));
> +      this.eventSeq.push(new invokerChecker(EVENT_SHOW, "newChildDoc"));

pls add testing for two HIDE events as well

nit, I would prefer styling
this.eventSeq = [
  new invokerChecker(),
  new invokerChecker()
];

@@ +38,5 @@
> +      }
> +
> +      this.finalCheck = function runTest_finalCheck()
> +      {
> +      ok(true, "dummy test");

you don't have to have finalCheck iirc and that fake ok()
Attachment #8648170 - Flags: review?(surkov.alexander) → review+
https://hg.mozilla.org/mozilla-central/rev/4d2723bc0bcb
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox43: --- → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
(Reporter)

Updated

3 years ago
Blocks: 1195940
(Reporter)

Comment 8

3 years ago
Definitely fixed, can we uplift to aurora? 42.0a2 has the same problem.
Flags: needinfo?(tbsaunde+mozbugs)
(Assignee)

Comment 9

3 years ago
(In reply to Jim Mathies [:jimm] from comment #8)
> Definitely fixed, can we uplift to aurora? 42.0a2 has the same problem.

its not e10s only, and I'm a little concerned about fall out, but I guess its kind of early.  surkov thoughts?
Flags: needinfo?(tbsaunde+mozbugs)
Flags: needinfo?(surkov.alexander)
(In reply to Trevor Saunders (:tbsaunde) from comment #9)
> (In reply to Jim Mathies [:jimm] from comment #8)
> > Definitely fixed, can we uplift to aurora? 42.0a2 has the same problem.
> 
> its not e10s only, and I'm a little concerned about fall out, but I guess
> its kind of early.  surkov thoughts?

same worries, but taking into account that no known regressions so far and major of testing doesn't happen on nightly then it's probably ok for uplifting.
Flags: needinfo?(surkov.alexander)
(Reporter)

Comment 11

3 years ago
Comment on attachment 8648170 [details] [diff] [review]
only coalesce reorder events when a previous one for the same target is obsolete

Approval Request Comment
[Feature/regressing bug #]:
a11y e10s support
[User impact if declined]:
crashes, bug 1116884 incident rates stay elevated
[Describe test coverage new/current, TreeHerder]:
landed on mc on the 19th, no issues this far.
[Risks and why]:
could regress something undetected.
[String/UUID change made/needed]:
none
Attachment #8648170 - Flags: approval-mozilla-aurora?
status-firefox42: --- → affected
Comment on attachment 8648170 [details] [diff] [review]
only coalesce reorder events when a previous one for the same target is obsolete

We want to fix a11y
Attachment #8648170 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Reporter)

Comment 14

3 years ago
This still shows up on aurora. Opening this back up so we can track on it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Severity: normal → critical
status-firefox41: --- → ?
status-firefox43: fixed → affected
status-firefox44: --- → ?
Whiteboard: KillHard
Target Milestone: mozilla43 → ---
Version: Trunk → 42 Branch
OS: Unspecified → Windows
Hardware: Unspecified → All
Jim is there a place I can look to see if this killhard still happens? (on nightly)
Flags: needinfo?(jmathies)
(Reporter)

Comment 16

3 years ago
(In reply to David Bolter [:davidb] from comment #15)
> Jim is there a place I can look to see if this killhard still happens? (on
> nightly)

Currently isn't around - 

http://www.mathies.com/mozilla/client-abort-report-nightly.txt
http://www.mathies.com/mozilla/client-abort-report-aurora.txt
http://www.mathies.com/mozilla/client-abort-report-beta.txt
Flags: needinfo?(jmathies)
(Assignee)

Comment 17

3 years ago
(In reply to Jim Mathies [:jimm] from comment #16)
> (In reply to David Bolter [:davidb] from comment #15)
> > Jim is there a place I can look to see if this killhard still happens? (on
> > nightly)
> 
> Currently isn't around - 

any reason to believe it isn't fixed?

Comment 18

3 years ago
e10s is now disabled when acessibility is on, that's probably the reason these crashes are gone.

Before that I got 2 crashes while browsing and opening pages from www.9gag.com, and both have
ipc_channel_error (msgtype=0x560008,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized, but the handler returned false (indicating failure)
(Reporter)

Updated

3 years ago
Duplicate of this bug: 1272815
(Reporter)

Updated

3 years ago
Crash Signature: [@ IPCError-browser | (msgtype=0x580009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,]
(Reporter)

Updated

3 years ago
Summary: PDocAccessible::Msg_BindChildDoc KillHard aborts → Crash in IPCError-browser | (msgtype=0x580009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized
(Reporter)

Updated

3 years ago
status-firefox41: ? → ---
status-firefox42: fixed → ---
status-firefox43: affected → ---
status-firefox44: ? → ---
Whiteboard: KillHard → KillHard, aes-win
(Reporter)

Updated

3 years ago
Whiteboard: KillHard, aes-win → KillHard, aes+
(Reporter)

Updated

3 years ago
Crash Signature: [@ IPCError-browser | (msgtype=0x580009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] → [@ IPCError-browser | (msgtype=0x580009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] [IPCError-browser | (msgtype=0x560009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,]
(Reporter)

Updated

3 years ago
Crash Signature: [@ IPCError-browser | (msgtype=0x580009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] [IPCError-browser | (msgtype=0x560009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] → [@ IPCError-browser | (msgtype=0x580009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] [@ IPCError-browser | (msgtype=0x560009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,]
Still happening in nightly.
(Assignee)

Updated

3 years ago
Depends on: 1272709
(Assignee)

Updated

3 years ago
Depends on: 1272706
No longer depends on: 1272709
(Assignee)

Updated

3 years ago
Depends on: 1268200
Crash Signature: [@ IPCError-browser | (msgtype=0x580009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] [@ IPCError-browser | (msgtype=0x560009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] → [@ IPCError-browser | (msgtype=0x580009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] [@ IPCError-browser | (msgtype=0x560009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] [@ IP…
Priority: -- → P2
Crash volume for signature 'IPCError-browser | (msgtype=0x560009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,':
 - nightly (version 50): 16 crashes from 2016-06-06.
 - aurora  (version 49): 106 crashes from 2016-06-07.
 - beta    (version 48): 0 crash from 2016-06-06.
 - release (version 47): 0 crash from 2016-05-31.
 - esr     (version 45): 0 crash from 2016-04-07.

Crash volume on the last weeks:
             Week N-1   Week N-2   Week N-3   Week N-4   Week N-5   Week N-6   Week N-7
 - nightly          0          0          0          0          0          3         13
 - aurora          13          9         17         27         10         24          1
 - beta             0          0          0          0          0          0          0
 - release          0          0          0          0          0          0          0
 - esr              0          0          0          0          0          0          0

Affected platforms: Windows, Mac OS X, Linux
status-firefox49: --- → affected
status-firefox50: --- → affected
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1291621
Duplicate of this bug: 1307389
Crash Signature: [@ IPCError-browser | (msgtype=0x580009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] [@ IPCError-browser | (msgtype=0x560009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] [@ IP… → [@ IPCError-browser | (msgtype=0x580009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] [@ IPCError-browser | (msgtype=0x560009,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] [@ IP…
Blocks: 1258839
(Reporter)

Comment 24

2 years ago
Looks like bug 1270916 may have addressed this.
I've been hitting this once a day on FF51 beta.  Jim, any ideas why I would be triggering this on beta?

https://crash-stats.mozilla.com/report/index/bp-2e3d625c-820b-4ccb-b140-18b032161121
https://crash-stats.mozilla.com/report/index/bp-b8ba88cc-9187-46d7-b96f-7e0992161122

Note, I briefly enabled the windows emoji keyboard the other day, but I have it disabled now.  Did that put me into some kind of accessibility mode?  How do I disable that?  (I have e10s forced on.)
Flags: needinfo?(jmathies)
(Reporter)

Comment 26

2 years ago
(In reply to Ben Kelly [:bkelly] from comment #25)
> I've been hitting this once a day on FF51 beta.  Jim, any ideas why I would
> be triggering this on beta?
> 
> https://crash-stats.mozilla.com/report/index/bp-2e3d625c-820b-4ccb-b140-
> 18b032161121
> https://crash-stats.mozilla.com/report/index/bp-b8ba88cc-9187-46d7-b96f-
> 7e0992161122
> 
> Note, I briefly enabled the windows emoji keyboard the other day, but I have
> it disabled now.  Did that put me into some kind of accessibility mode?  How
> do I disable that?  (I have e10s forced on.)

Check to see if you have a11y enabled through about:support. You may hit this if you have e10s forced on and you have some sort of touch screen laptop or soft keyboard active.
Flags: needinfo?(jmathies)
(Reporter)

Updated

2 years ago
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago2 years ago
Resolution: --- → FIXED
I ran into this issue with latest Aurora 52.0a2 (2016-12-14) while testing touch events in APZ. The crash happened on mashable.com using Dell XPS 12, Windows 10 x64. 
 - https://crash-stats.mozilla.com/report/index/cf796ca5-d569-46e9-8397-bcba02161214

It seems that are still some recent crashes on 52.0a2 from the stats signatures.

Comment 28

2 years ago
Just wanted to chime in to say that I have another "common scenario" that causes this error, I think.
- Using Windows 10 Insider Preview Build 14986
- Using Firefox 50.0.1.0 x86

Sometimes, if I
- Go to https://www.neowin.net
- Hover over the "Facebook Twitter Google+" image in the header
- POOF. "Bad news first: This tab has crashed"

It doesn't happen all the time, and I can't pin down why. I think it has something to do with how many Flash objects I've previously loaded in the session. Not sure.

Regards,
Jacob

Comment 29

2 years ago
Note: I have e10s forced on, with a few extensions installed.
(In reply to Jacob W. Klein from comment #29)
> Note: I have e10s forced on, with a few extensions installed.

That's the price of force-enabling e10s, I'm afraid. We are currently focusing on 52-53 for stabilizing touch and a11y on e10s.
You need to log in before you can comment on or make changes to this bug.