844074 - crash in nsAccessibilityService::CreateAccessibleForDeckChild

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Scoobidiver (away)]

There are a few crashes in 19.0 (throttle of 10%).

Signature 	nsAccessibilityService::CreateAccessibleForDeckChild(nsIFrame*, nsIContent*, mozilla::a11y::DocAccessible*) More Reports Search
UUID	21710411-5fa2-4fa0-ad32-f81b32130220
Date Processed	2013-02-20 11:38:44
Uptime	1909
Last Crash	more than 3 months before submission
Install Age	31.8 minutes since version was first installed.
Install Time	2013-02-20 11:06:01
Product	Firefox
Version	19.0
Build ID	20130218165021
Release Channel	release
OS	Linux
OS Version	0.0.0 Linux 2.6.32-45-generic #103-Ubuntu SMP Thu Feb 7 22:19:08 UTC 2013 x86_64
Build Architecture	amd64
Build Architecture Info	family 15 model 35 stepping 2
Crash Reason	SIGSEGV
Crash Address	0x0
User Comments	Crashed while running multiple audio stream players
App Notes 	
OpenGL: Advanced Micro Devices, Inc. -- Mesa DRI R600 (RV630 9589) 20090101  TCL -- 1.5 Mesa 7.7.1 -- texture_from_pixmap
Processor Notes 	sp-processor05.phx1.mozilla.com_30511:2008; exploitablity tool: ERROR: unable to analyze dump
EMCheckCompatibility	True	
Accessibility	Active

Frame 	Module 	Signature 	Source
0 	libxul.so 	nsAccessibilityService::CreateAccessibleForDeckChild 	nsAccessibilityService.cpp:1511
1 	libxul.so 	nsAccessibilityService::GetOrCreateAccessible 	nsAccessibilityService.cpp:926
2 	libxul.so 	mozilla::a11y::TreeWalker::NextChildInternal 	TreeWalker.cpp:90
3 	libxul.so 	mozilla::a11y::Accessible::CacheChildren 	TreeWalker.h:38
4 	libxul.so 	mozilla::a11y::Accessible::EnsureChildren 	Accessible.cpp:2996
5 	libxul.so 	mozilla::a11y::DocAccessible::ProcessContentInserted 	DocAccessible.cpp:1823
6 	libxul.so 	mozilla::a11y::NotificationController::ContentInsertion::Process 	NotificationController.cpp:887
7 	libxul.so 	mozilla::a11y::NotificationController::WillRefresh 	NotificationController.cpp:232
8 	libxul.so 	nsRefreshDriver::Notify 	nsRefreshDriver.cpp:347
9 	libxul.so 	nsTimerImpl::Fire 	nsTimerImpl.cpp:485
10 	libxul.so 	nsTimerEvent::Run 	nsTimerImpl.cpp:565
11 	libxul.so 	nsThread::ProcessNextEvent 	nsThread.cpp:627
12 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:238
13 	libxul.so 	mozilla::ipc::MessagePump::Run 	MessagePump.cpp:82
14 	libxul.so 	MessageLoop::Run 	message_loop.cc:208
15 	libxul.so 	nsBaseAppShell::Run 	nsBaseAppShell.cpp:163
16 	libxul.so 	nsAppStartup::Run 	nsAppStartup.cpp:290
17 	libxul.so 	XREMain::XRE_mainRun 	nsAppRunner.cpp:3823
18 	libxul.so 	XREMain::XRE_main 	nsAppRunner.cpp:3890
19 	libxul.so 	XRE_main 	nsAppRunner.cpp:4084
20 	firefox 	main 	nsBrowserApp.cpp:174 

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsAccessibilityService%3A%3ACreateAccessibleForDeckChild%28nsIFrame*%2C+nsIContent*%2C+mozilla%3A%3Aa11y%3A%3ADocAccessible*%29

Comment 1

[alexander :surkov (:asurkov)]

it seems a dead frame object: http://mxr.mozilla.org/mozilla-release/source/accessible/src/base/nsAccessibilityService.cpp#1511

Comment 2

[alexander :surkov (:asurkov)]

technically we can't trust nsAccessibilityService::CreateAccessibleByType since it gets nsIAccessibleProvider which is implemented by XBL binding and calls accessibleType property. It doesn't necessary with this crash but that's something we need to rethink to be on safe side.

Comment 3

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #2)
> technically we can't trust nsAccessibilityService::CreateAccessibleByType
> since it gets nsIAccessibleProvider which is implemented by XBL binding and
> calls accessibleType property. It doesn't necessary with this crash but

not necessarily what's at fault, but it seems like a good guess.

> that's something we need to rethink to be on safe side.

I'm really not sure what to do here, making it safe to call into js here sounds like a pretty bad / expensive thing to do.  The tag for xul elements is somehow magically set by the binding right?  can we just use that and kill the nsIAccessibleProvider stuff?

Comment 4

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #3)
> (In reply to alexander :surkov from comment #2)
> > technically we can't trust nsAccessibilityService::CreateAccessibleByType
> > since it gets nsIAccessibleProvider which is implemented by XBL binding and
> > calls accessibleType property. It doesn't necessary with this crash but
> 
> not necessarily what's at fault, but it seems like a good guess.

afaik our toolkit is safe but those crash reports has bunch of addons, so it could be

> > that's something we need to rethink to be on safe side.
> 
> I'm really not sure what to do here, making it safe to call into js here
> sounds like a pretty bad / expensive thing to do.  The tag for xul elements
> is somehow magically set by the binding right?  can we just use that and
> kill the nsIAccessibleProvider stuff?

I think it could be easy: replace nsIAccessibleProvider::accessibleType to attributes like @role="xul:alert". If that's a good idea to mix with ARIA.

Comment 5

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #4)
> (In reply to Trevor Saunders (:tbsaunde) from comment #3)
> > (In reply to alexander :surkov from comment #2)
> > > technically we can't trust nsAccessibilityService::CreateAccessibleByType
> > > since it gets nsIAccessibleProvider which is implemented by XBL binding and
> > > calls accessibleType property. It doesn't necessary with this crash but
> > 
> > not necessarily what's at fault, but it seems like a good guess.
> 
> afaik our toolkit is safe but those crash reports has bunch of addons, so it
> could be

well, I guess it might also be the xul tree stuff in bug 809871

> > > that's something we need to rethink to be on safe side.
> > 
> > I'm really not sure what to do here, making it safe to call into js here
> > sounds like a pretty bad / expensive thing to do.  The tag for xul elements
> > is somehow magically set by the binding right?  can we just use that and
> > kill the nsIAccessibleProvider stuff?
> 
> I think it could be easy: replace nsIAccessibleProvider::accessibleType to
> attributes like @role="xul:alert". If that's a good idea to mix with ARIA.

hm, if you only do that for xul stuff so that content can't do it that seems fine.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #5)

> well, I guess it might also be the xul tree stuff in bug 809871

true, it's not assigned to you but you have patches. Do you work on it/have plans?

> > I think it could be easy: replace nsIAccessibleProvider::accessibleType to
> > attributes like @role="xul:alert". If that's a good idea to mix with ARIA.
> 
> hm, if you only do that for xul stuff so that content can't do it that seems
> fine.

having it visible from content might be not so bad.

Comment 7

[Trevor Saunders (:tbsaunde)]

(In reply to Scoobidiver from comment #0)
> There are a few crashes in 19.0 (throttle of 10%).

Does this appear to be related to any particular addons?

Comment 8

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #6)
> (In reply to Trevor Saunders (:tbsaunde) from comment #5)
> 
> > well, I guess it might also be the xul tree stuff in bug 809871
> 
> true, it's not assigned to you but you have patches. Do you work on it/have
> plans?

not particularly, I could work on it but I also have the doc cache thing and reviews to do so probably not for a day or two.

> > > I think it could be easy: replace nsIAccessibleProvider::accessibleType to
> > > attributes like @role="xul:alert". If that's a good idea to mix with ARIA.
> > 
> > hm, if you only do that for xul stuff so that content can't do it that seems
> > fine.
> 
> having it visible from content might be not so bad.

maybbe, we sort of already do as aria grid and cell.  In any case the only time nsIAccessibleProvider appears to be used is for xul so we can worry about content later.

Comment 9

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #8)

> > true, it's not assigned to you but you have patches. Do you work on it/have
> > plans?
> 
> not particularly, I could work on it but I also have the doc cache thing and
> reviews to do so probably not for a day or two.

this is fine, if you can finish them in Firefox 21 timeframe then it'd be great.

> > > > I think it could be easy: replace nsIAccessibleProvider::accessibleType to
> > > > attributes like @role="xul:alert". If that's a good idea to mix with ARIA.
> > > 
> > > hm, if you only do that for xul stuff so that content can't do it that seems
> > > fine.
> > 
> > having it visible from content might be not so bad.
> 
> maybbe, we sort of already do as aria grid and cell.  In any case the only
> time nsIAccessibleProvider appears to be used is for xul so we can worry
> about content later.

right. I'll file a bug.

Comment 10

[Scoobidiver (away)]

(In reply to Trevor Saunders (:tbsaunde) from comment #7)
> Does this appear to be related to any particular addons?
With such a low volume per day (no correlations per week), correlations are not representative and are often caused by duplicates:
     42% (5/12) vs.  16% (154/937) {b9db16a4-6edc-47ec-a1f4-b86292ed211d} (Video DownloadHelper, https://addons.mozilla.org/addon/3006)
     42% (5/12) vs.  18% (170/937) [e-mail]
     25% (3/12) vs.  13% (121/937) [e-mail]
     17% (2/12) vs.   5% (47/937) {c0c9a2c7-2e5c-4447-bc53-97718bc91e1b} (Easy YouTube Video Downloader, https://addons.mozilla.org/addon/10137)
     83% (10/12) vs.  72% (673/937) [e-mail]
     92% (11/12) vs.  82% (771/937) [e-mail]

Comment 11

[alexander :surkov (:asurkov)]

(In reply to Scoobidiver from comment #10)
> (Video DownloadHelper, https://addons.mozilla.org/addon/3006)

this one contains a lot of XUL trees

Comment 12

[alexander :surkov (:asurkov)]

there's no such method any longer, closing as wfm