crash in mozilla::a11y::ProxyShowHideEvent

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
3 years ago
2 years ago

People

(Reporter: davidb, Assigned: tbsaunde)

Tracking

({crash, topcrash-linux})

unspecified
Unspecified
Linux
crash, topcrash-linux
Points:
---

Firefox Tracking Flags

(platform-rel -, firefox47 unaffected, firefox48+ fixed, firefox49+ fixed)

Details

(Whiteboard: [platform-rel-Google] [platform-rel-Gmail], crash signature)

Attachments

(1 attachment)

This bug was filed from the Socorro interface and is 
report bp-b67fe5ad-e495-41b6-acd5-d0da02160424.
=============================================================

More here: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=mozilla%3A%3Aa11y%3A%3AProxyShowHideEvent#tab-reports

Earliest build id seems to be: 20160423030220
Suspect caused by recent landings in bug 1262563.
Crash URLs sort of match expected user browser activity... Facebook is most popular.
This is the #1 topcrash on recent Linux Nightly builds. Looks like it's usually a null pointer deref.
I can pretty much reliable reproduce this:

1) Go to gmail.com
2) Try to create a new email
3) Add a recipient. I start by inputting "jm" and when pressing 'm' it crashes.

What can I add to this bug to help facilitate this forward?
[Tracking Requested - why for this release]:

Linux Nightly #1 topcrash.
tracking-firefox48: --- → ?
tracking-firefox49: --- → ?
Assignee: nobody → tbsaunde+mozbugs
Flags: needinfo?(hv1989)
Flags: needinfo?(hv1989)
(In reply to Hannes Verschore [:h4writer] from comment #4)
> I can pretty much reliable reproduce this:
> 
> 1) Go to gmail.com
> 2) Try to create a new email
> 3) Add a recipient. I start by inputting "jm" and when pressing 'm' it
> crashes.
> 
> What can I add to this bug to help facilitate this forward?

Thanks Hannes. Trevor just landed a potential fix from bug 1267376. If you could try a build with that patch it would be great.
Flags: needinfo?(hv1989)
(Assignee)

Comment 7

3 years ago
Ok, I can reproduce.  In a debug build we assert consumed == aData.NewTree().Length() so I suspect the patch for bug 1267376 is very likely to fix this.
Flags: needinfo?(hv1989)
Tracking for 48 and 49 since this is a recent regression. Once you have a patch, please request uplift to aurora if you think it’s safe, so we don’t ship with this regression.
status-firefox47: --- → unaffected
tracking-firefox48: ? → +
tracking-firefox49: ? → +
(In reply to David Bolter [:davidb] from comment #6)
> Thanks Hannes. Trevor just landed a potential fix from bug 1267376. If you
> could try a build with that patch it would be great.

I tried this with build:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=d70ec2a35552&selectedJob=26322359
http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-linux64/1461260100/

Still got a crash:
https://crash-stats.mozilla.com/report/index/a5187205-72a9-487a-9209-a20e02160428
Not sure how to add symbols in there. But I assume it shows no meaningful information, since it is non-official build?
Created attachment 8746464 [details]
Debug build after bug 1267376 landed: mozilla::a11y::DocAccessibleParent::RecvShowEvent

Used a debug build and got the following backtrace.
See Also: → bug 1268473
(Assignee)

Comment 11

3 years ago
(In reply to Hannes Verschore [:h4writer] from comment #10)
> Created attachment 8746464 [details]
> Debug build after bug 1267376 landed:
> mozilla::a11y::DocAccessibleParent::RecvShowEvent
> 
> Used a debug build and got the following backtrace.

I'd expect you still hit that assert, and it adds evidence to the theory its the same issue as bug 1267376.

(In reply to Hannes Verschore [:h4writer] from comment #9)
> (In reply to David Bolter [:davidb] from comment #6)
> > Thanks Hannes. Trevor just landed a potential fix from bug 1267376. If you
> > could try a build with that patch it would be great.
> 
> I tried this with build:
> https://treeherder.mozilla.org/#/jobs?repo=mozilla-
> inbound&revision=d70ec2a35552&selectedJob=26322359
> http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-
> linux64/1461260100/
> 
> Still got a crash:
> https://crash-stats.mozilla.com/report/index/a5187205-72a9-487a-9209-
> a20e02160428
> Not sure how to add symbols in there. But I assume it shows no meaningful
> information, since it is non-official build?

I'm not sure why you still hit that, if I test with a --disable-debug build with bug 1267376 applied it doesn't crash.
(In reply to Trevor Saunders (:tbsaunde) from comment #11)
> I'd expect you still hit that assert, and it adds evidence to the theory its
> the same issue as bug 1267376.

I hit this assert on a debug build with bug 1267376 inclusive. Could it be it doesn't fix the issue fully?
(Assignee)

Comment 13

3 years ago
(In reply to Hannes Verschore [:h4writer] from comment #12)
> (In reply to Trevor Saunders (:tbsaunde) from comment #11)
> > I'd expect you still hit that assert, and it adds evidence to the theory its
> > the same issue as bug 1267376.
> 
> I hit this assert on a debug build with bug 1267376 inclusive. Could it be
> it doesn't fix the issue fully?

yes, that's expected and its not supposed to fix all the issues.
status-firefox48: --- → affected
status-firefox49: --- → affected
#3 in top-crashes for aurora
Keywords: topcrash-linux
This crash signature isn't showing up in the last 14 days on any channel. Should we declare this fixed? 
Hannes, can you still reproduce the crash you described in comment 4?
Flags: needinfo?(tbsaunde+mozbugs)
Flags: needinfo?(hv1989)
No, I can't reproduce anymore. It doesn't happen locally for me anymore since a few weeks. Possibly similar date to when the crash signature disappeared.
Flags: needinfo?(hv1989)
Please reopen if it reappears. Closing WFM as per comment #16.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(tbsaunde+mozbugs)
Resolution: --- → WORKSFORME
status-firefox48: affected → fixed
status-firefox49: affected → fixed
platform-rel: --- → -
Whiteboard: [platform-rel-Google] [platform-rel-Gmail]
You need to log in before you can comment on or make changes to this bug.