Closed Bug 1218762 Opened 4 years ago Closed 4 years ago

[E10S] crash in mozilla::a11y::ia2Accessible::scrollTo

Categories

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

x86_64
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla45
Tracking Status
e10s + ---
firefox45 --- fixed

People

(Reporter: MarcoZ, Assigned: tbsaunde)

References

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

This bug was filed from the Socorro interface and is 
report bp-75f62c7d-d1b5-4127-8b0a-e82b12151027.
=============================================================

This happens any time NVDA tries to scroll to something like a link, when downarrowing through a page. Happens on the Firefox First Run page and other pages. Reliably reproducible.
tracking-e10s: --- → +
Is Document() failing?
Alex can you take or help find an owner?
Flags: needinfo?(surkov.alexander)
(In reply to David Bolter [:davidb] from comment #2)
> Alex can you take or help find an owner?

you may add Document() check to fix a crash but then it likely means you should add it to all other paths. I'm not sure how that thing can get out of sync with IsDefunct state, but since it's e10s thing then Trevor or you may have some ideas on it. Maybe the reason of the crash is the method wasn't proxied yet.
Flags: needinfo?(surkov.alexander)
OK thanks. Trevor said he'd get to it this week.
Assignee: nobody → tbsaunde+mozbugs
Attachment #8689145 - Flags: review?(dbolter) → review+
https://hg.mozilla.org/mozilla-central/rev/6c9566ca9ed1
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
Starting with this push, Android 4.3 API11+ debug started perma-failing: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&tochange=14bd25c63912&fromchange=be035c256991&selectedJob=17630542&filter-searchStr=R%28C2%29

14:20:14     INFO -  REFTEST TEST-START | http://10.0.2.2:8854/tests/gfx/tests/crashtests/408754-1.html
14:20:14     INFO -  REFTEST TEST-LOAD | http://10.0.2.2:8854/tests/gfx/tests/crashtests/408754-1.html | 118 / 738 (15%)
14:20:26     INFO -  REFTEST TEST-PASS | http://10.0.2.2:8854/tests/gfx/tests/crashtests/408754-1.html | (LOAD ONLY)
14:20:26     INFO -  REFTEST INFO | Loading a blank page
14:20:26     INFO -  REFTEST TEST-UNEXPECTED-FAIL | http://10.0.2.2:8854/tests/gfx/tests/crashtests/408754-1.html | assertion count 1 is more than expected 0 assertions

Failing test: https://dxr.mozilla.org/mozilla-central/rev/7883e81f3c305078353ca27a6b1adb8c769d5904/gfx/tests/crashtests/408754-1.html

Please fix it or back it out.
Flags: needinfo?(tbsaunde+mozbugs)
Heh, fix a Fennec assertion failure. As I explained to them, red faced and screaming, when they insisted on running debug tests, the only way to fix a Fennec assertion failure is to remove every single assertion from the tree, because they do not log what assertion failed.

Annotated, instead.
Flags: needinfo?(tbsaunde+mozbugs)
Ah, I'd forgotten in the year since there was last any activity around Fennec assertions that it actually is possible to find what failed, you just have to know of the existence of a separate log, and then match up timestamps between the two logs because the log with the assertions in it doesn't have anything to say what test is running except for tests which happen to hit a JS error in a timely manner and thus report the test name via the file which hit the error.

So the assertion failure is (most likely, almost certainly) "ASSERTION: didn't subtract all that we added: '(space == 0 || space == nscoord_MAX) && ((l2t == FLEX_PCT_LARGE) ? (-0.001f < basis.f && basis.f < 0.001f) : (basis.c == 0 || basis.c == nscoord_MAX))', file /builds/slave/m-in-and-api-11-d-000000000000/build/src/layout/tables/BasicTableLayoutStrategy.cpp, line 1073".
(In reply to Phil Ringnalda (:philor) from comment #11)
> Heh, fix a Fennec assertion failure. As I explained to them, red faced and
> screaming, when they insisted on running debug tests, the only way to fix a
> Fennec assertion failure is to remove every single assertion from the tree,
> because they do not log what assertion failed.
> 
> Annotated, instead.

heh thanks.  I actually have no idea how this changed any behavior on !windows so that seems reasonablish to me.
You need to log in before you can comment on or make changes to this bug.