Closed Bug 1297131 Opened 3 years ago Closed 3 years ago

[e10s][a11y] Crash in IPCError-browser | (msgtype=0x5C000A,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,

Categories

(Core :: Disability Access APIs, defect, critical)

51 Branch
x86
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1270916
Tracking Status
e10s + ---
firefox51 - wontfix

People

(Reporter: alice0775, Unassigned)

References

Details

(Keywords: crash, regression, reproducible, Whiteboard: [STR in comment #2][aes+])

Crash Data

This bug was filed from the Socorro interface and is 
report bp-dbdeba6e-c697-45dc-b1e4-1476b2160822.
=============================================================

Reproducible : none

Steps to reproduce:
1. Search Facebook from SearchBar
2. Click a link in the results
   i.e., https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwi3p7ixwNXOAhVBtJQKHZkZClUQFggjMAA&url=https%3A%2F%2Fja-jp.facebook.com%2F&usg=AFQjCNF2AhfF-R00mWMvTx9TbBKZPxDMYQ
3. A Master Password Prompt pops up and enter master password and Clock[OK] 
4. Double click login id field in the top bar

Actual Results:
Crash
Reproduced the crash with the same STR.
bp-e4020113-4551-43ab-a768-8a04a2160822
Crash Signature: [@ IPCError-browser | (msgtype=0x5C000A,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] → [@ IPCError-browser | (msgtype=0x5C000A,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,] [@ IPCError-browser | (msgtype=0x2E0004,name=PBrowser::Msg_PDocAccessibleConstructor) Processing error: message was deseri]
[Tracking Requested - why for this release]:

Regression window(STR Comment 2)
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=85105a2f62d24ffe97e37ae70df08f6b23fe5e0f&tochange=b50c1f98bff8ae9efb5dc7ed3d0b53ac1bb8fa70

Suspect:
43d72f3a7ae1	Alexander Surkov — Bug 1274381 - scope accessible elements search to inserted nodes, r=yzen, f=marcoz
Blocks: 1274381
Flags: needinfo?(surkov.alexander)
Keywords: regression
We probably see here two different crashes, because bug 1274381, which was named guilty, was landed Aug 5 [1], but the crash path [2] was introduced later Aug 18 [3] by bug 1268544.

Can we have a crash stack before bug 1268544 was landed?

Aaron, could you please take a look at the crash stack too?

[1] https://hg.mozilla.org/integration/mozilla-inbound/rev/43d72f3a7ae1
[2] bp-e4020113-4551-43ab-a768-8a04a2160822
[3] https://hg.mozilla.org/mozilla-central/rev/ad2a728e5832
Flags: needinfo?(surkov.alexander)
With 16-Aug-2016 Nightly build cset 054d4856cea6150a6638e5daf7913713281af97d
(this does not include bug 1268544)

bp-ac4d511e-54bb-46bb-816d-085fa2160823
bp-dc2ded4d-d7a5-40fb-89ca-3f7a12160823
bp-2696e710-6862-4d2d-ab9f-a06092160823
(In reply to Alice0775 White from comment #5)
> With 16-Aug-2016 Nightly build cset 054d4856cea6150a6638e5daf7913713281af97d
> (this does not include bug 1268544)
> 
> bp-ac4d511e-54bb-46bb-816d-085fa2160823
> bp-dc2ded4d-d7a5-40fb-89ca-3f7a12160823
> bp-2696e710-6862-4d2d-ab9f-a06092160823

these are something 3d, as they don't have a11y on stack at all, I'm not sure why they share same crash signature.
(In reply to Alice0775 White from comment #7)

> Same suspicion Bug 1274381 ...
> 
> With 07-Aug-2016 Nightly x64 build cset
> d42aacfe34af25e2f5110e2ca3d24a210eabeb33
> bp-796085cc-be50-470f-ac55-ae4102160823
> bp-4b786282-4693-4f31-871c-72af02160823
> bp-b95c1695-166e-41ca-bf6a-57e8f2160823

there's definitely something weird with the stacks, these three are all different and contain no a11y calls. Does anyone have ideas? What tool did you use to find the suspicion? I wish to have a better idea on how it finds it based on such questionable stacks.

(In reply to Alice0775 White from comment #0)
> Steps to reproduce:
> 1. Search Facebook from SearchBar
> 2. Click a link in the results
>    i.e.,
> https://www.google.co.jp/
> url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwi3p7ixwNXO
> AhVBtJQKHZkZClUQFggjMAA&url=https%3A%2F%2Fja-jp.facebook.
> com%2F&usg=AFQjCNF2AhfF-R00mWMvTx9TbBKZPxDMYQ
> 3. A Master Password Prompt pops up and enter master password and Clock[OK] 

it doesn't popup up for me, what does make it to pop up?
You should set Master password from Option > Security.
I think STR comment#2 is easy to reproduce the crash.

By the way, 
The following preference seems to prevent the crash.
user_pref("accessibility.force_disabled", 1);
(In reply to Alice0775 White from comment #9)
> You should set Master password from Option > Security.
> I think STR comment#2 is easy to reproduce the crash.

I see the crash, but no a11y on stack, it crashes inside PressShell::Paint while building display lists, similar to crashes from comment #5. It would be definitely good to show this to a layout peer.

> By the way, 
> The following preference seems to prevent the crash.
> user_pref("accessibility.force_disabled", 1);

it's interesting, a11y seems correlates with the crash quite implicitly.
(In reply to Alice0775 White from comment #7)
> Regression window(m-i x64)
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=85105a2f62d24ffe97e37ae70df08f6b23fe5e0f&tochange=43d7
> 2f3a7ae103cb195a6aff1e65defddf8209b9
> 
> Same suspicion Bug 1274381 ...

nah, its basically just a specific case of bug 1185277, which is caused by the same issues as bug 1272706.  Note I'm not done debugging yet, but I'm pretty sure from what I've seen so far.  Of course that bug may have made it worse or something.

(In reply to alexander :surkov from comment #8)
> (In reply to Alice0775 White from comment #7)
> 
> > Same suspicion Bug 1274381 ...
> > 
> > With 07-Aug-2016 Nightly x64 build cset
> > d42aacfe34af25e2f5110e2ca3d24a210eabeb33
> > bp-796085cc-be50-470f-ac55-ae4102160823
> > bp-4b786282-4693-4f31-871c-72af02160823
> > bp-b95c1695-166e-41ca-bf6a-57e8f2160823
> 
> there's definitely something weird with the stacks, these three are all
> different and contain no a11y calls. Does anyone have ideas? What tool did
> you use to find the suspicion? I wish to have a better idea on how it finds
> it based on such questionable stacks.

the stacks are probably fine, they're just irrelevant.  The problem is the main process got sent a bad async message, so the content process got killed, but its off doing something unrelated, and so the stack is uninteresting.
Tracking 51+ for this crash, especially since it is a regression and reproducible.
For some reason socorro is displaying the wrong process in many of these dumps. It's showing content stacks when it's the chrome stack that has crashed.
Whiteboard: [STR in comment #2]
tracking-e10s: --- → ?
Summary: Crash in IPCError-browser | (msgtype=0x5C000A,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized, → [e10s][a11y] Crash in IPCError-browser | (msgtype=0x5C000A,name=PDocAccessible::Msg_BindChildDoc) Processing error: message was deserialized,
Starting with the latest Nightly (or so) on OS X, I'm getting almost 100% crashes with this signature when I load Facebook.

bp-370b2ff9-2e9f-4cdf-bb92-a54fa2160914
bp-aed8ff59-c933-475c-9bfa-08be12160914
bp-494d0bb3-669f-4127-89ff-0c47e2160914
Whiteboard: [STR in comment #2] → [STR in comment #2][aes+]
On IRC Trevor said this is basically a dupe of bug 1270916, so duping over.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1270916
This is still affecting 51, but it won't be for 51 beta. So we aren't tracking for 51 in the duplicate bug - only for 52.
Mark 51 won't fix as the volume of crash is low.
You need to log in before you can comment on or make changes to this bug.