talos a11y crashes when run in e10s mode

RESOLVED FIXED in mozilla37

Status

RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: jmaher, Assigned: tbsaunde)

Tracking

Trunk
mozilla37
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+)

Details

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
this is one of the few remaining talos tests to get fixed/investigated for e10s mode.  I spent some time looking into this and can easily reproduce the crash on a local (linux64) build of firefox.

This test runs fine while run without e10s, but we seem to crash when we get to the sendAsyncMessage(..) call.  What is odd is that other tests can use this with no problem.

Here is the area in the code that is crashing:
http://hg.mozilla.org/build/talos/file/2bdbc49134c4/talos/page_load_test/a11y/dhtml.html#l42

I am sure there are other things that could be done to narrow this down more, I will count on the expertise of others to help me figure out what else to try.
(Reporter)

Comment 1

4 years ago
actually this line is causing us to fail:
http://hg.mozilla.org/build/talos/file/2bdbc49134c4/talos/page_load_test/a11y/a11y.js#l15
      gAccRetrieval =
      Components.classes["@mozilla.org/accessibleRetrieval;1"]
                .getService(Components.interfaces.nsIAccessibleRetrieval);

I am not familiar with these tests, or how a11y works (or if it should work with e10s), but this is what is getting in the way of us enabling this test for e10s talos.

:davidb, any thoughts on this?
Flags: needinfo?(dbolter)
Heyo. Can you post a crash stack?
Flags: needinfo?(dbolter)
Flags: needinfo?(jmaher)
tracking-e10s: --- → +
(Assignee)

Comment 4

4 years ago
(In reply to Joel Maher (:jmaher) from comment #3)
> Created attachment 8522501 [details]
> a11y_e10s_crash.txt
> 
> this is the dump from mozcrash, I am using this build (linux64):
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> inbound-linux64/1415912590/firefox-36.0a1.en-US.linux-x86_64.tar.bz2

This looks like bug 1097614, but with a better stack and str.

Given the stack I think what's going on is we recieve PDocAccessibleConstructor message while nsAccessibilityService::gAccService is null, but I'm not yet sure how that's possible.

Updated

4 years ago
Blocks: 1029143
Assignee: nobody → tbsaunde+mozbugs
(Assignee)

Comment 5

4 years ago
Created attachment 8533451 [details] [diff] [review]
Allow PDocAccessibleConstructor to be recieved when gAccessibilityService doesn't exist

Talos causes accessibility to be instantiated only in the content
process.  That means PDocAccessibleConstructor messages can be recieved
by the parent when GetAccService() returns null.  The easiest way of
dealing with this is moving DocManager::mRemoteDocuments from a member
of the acc service singleton to its own global.  That means the parent
process can track accessible documents in child processes without
instantiating a11y in the parent process.
Attachment #8533451 - Flags: review?(surkov.alexander)
why to care about managing the remote documents if AccService wasn't instantiated?
(Assignee)

Comment 7

4 years ago
(In reply to alexander :surkov from comment #6)
> why to care about managing the remote documents if AccService wasn't
> instantiated?

it might be in the future though
so you create accessibility related objects in content and/or main processes even if no accessibility running?
(Assignee)

Comment 9

4 years ago
(In reply to alexander :surkov from comment #8)
> so you create accessibility related objects in content and/or main processes
> even if no accessibility running?

no, if accessibility is running in child but not parent then parent still tracks what documents child has.  How was that not clear from the commit message?
how many instances of AccService you have, one per process?
(Assignee)

Comment 11

4 years ago
(In reply to alexander :surkov from comment #10)
> how many instances of AccService you have, one per process?

yes
Comment on attachment 8533451 [details] [diff] [review]
Allow PDocAccessibleConstructor to be recieved when gAccessibilityService doesn't exist

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

it makes sense, r=me

::: accessible/base/DocManager.h
@@ +80,5 @@
>      MOZ_ASSERT(result, "Why didn't we find the document!");
>    }
>  
>    /*
>     * Notify of a new top level document in a content process.

maybe 'Notify the main process of ...'

@@ +173,5 @@
>      XPCDocumentHashtable;
>    XPCDocumentHashtable mXPCDocumentCache;
>  
>    /*
>     * The list of remote top level documents.

maybe it'd be good to add ', used by (kept in) main process' to make it clear it's not used in content processes.
Attachment #8533451 - Flags: review?(surkov.alexander) → review+
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/97df7d232e7f for leaking in pretty much every test suite:
https://treeherder.mozilla.org/ui/logviewer.html#?job_id=4474474&repo=mozilla-inbound
Flags: needinfo?(tbsaunde+mozbugs)
(Assignee)

Comment 16

4 years ago
Created attachment 8534605 [details] [diff] [review]
Allow PDocAccessibleConstructor to be recieved when gAccessibilityService doesn't exist

Talos causes accessibility to be instantiated only in the content
process.  That means PDocAccessibleConstructor messages can be recieved
by the parent when GetAccService() returns null.  The easiest way of
dealing with this is moving DocManager::mRemoteDocuments from a member
of the acc service singleton to its own global.  That means the parent
process can track accessible documents in child processes without
instantiating a11y in the parent process.
Attachment #8534605 - Flags: review?(surkov.alexander)
Attachment #8534605 - Flags: review?(surkov.alexander) → review+
https://hg.mozilla.org/mozilla-central/rev/0835ea5fd49d
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
(Assignee)

Updated

3 years ago
Flags: needinfo?(tbsaunde+mozbugs)
You need to log in before you can comment on or make changes to this bug.