628104 - Firefox 4.0b10pre Crash Report [@ nsDocAccessible::UpdateTree(nsAccessible*, nsIContent*, int) ]

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Carsten Book [:Tomcat]]

http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&date=2011-01-23%2000%3A00%3A00&signature=nsDocAccessible%3A%3AUpdateTree%28nsAccessible*%2C%20nsIContent*%2C%20int%29&version=Firefox%3A4.0b10pre -> Windows NT - Crash Reports for nsDocAccessible::UpdateTree(nsAccessible*, nsIContent*, int)

so far no comments mentioned for reproducing this crash

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsDocAccessible::UpdateTree 	accessible/src/base/nsDocAccessible.cpp:1904
1 	xul.dll 	NotificationController::WillRefresh 	accessible/src/base/NotificationController.cpp:195
2 	xul.dll 	PresShell::FlushPendingNotifications 	layout/base/nsPresShell.cpp:4922
3 	xul.dll 	nsRefreshDriver::Notify 	layout/base/nsRefreshDriver.cpp:254
4 	xul.dll 	mozilla::TimeDuration::ToSeconds 	xpcom/ds/TimeStamp.cpp:63
5 	nspr4.dll 	PR_Unlock 	nsprpub/pr/src/threads/combined/prulock.c:347
6 	xul.dll 	TimerThread::UpdateFilter 	xpcom/threads/TimerThread.cpp:236
7 	xul.dll 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:428
8 	xul.dll 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:517
9 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
10 	xul.dll 	TimerThread::RemoveTimer 	xpcom/threads/TimerThread.cpp:429
11 	xul.dll 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:250
12 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
13 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:202
14 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:176
15 	xul.dll 	nsThreadManager::GetCurrentThread 	xpcom/threads/nsThreadManager.cpp:222
16 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:192
17 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:217
18 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3699
19 	mozcrt19.dll 	arena_malloc_small 	obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:3783
20 	xul.dll 	nsTHashtable<CategoryLeaf>::s_MatchEntry 	obj-firefox/dist/include/nsTHashtable.h:375
21 	mozcrt19.dll 	arena_dalloc_small 	obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4138
22 	kernel32.dll 	kernel32.dll@0x4b605 	
23 	xul.dll 	nsAString_internal::ReplacePrep 	obj-firefox/dist/include/nsTSubstring.h:684
24 	xul.dll 	nsAString_internal::Assign 	xpcom/string/src/nsTSubstring.cpp:396
25 	xul.dll 	nsLocalFile::GetParent 	xpcom/io/nsLocalFileWin.cpp:2263

Comment 1

[Marco Zehe (:MarcoZ)]

Alex, is this bug 617300 or bug 498015 or related? Looks like it.

Comment 2

[Marco Zehe (:MarcoZ)]

For the record, wasn't me who sent in that crash report, I leave comments. And I haven't seen any crashiness.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to comment #1)
> Alex, is this bug 617300 or bug 498015 or related? Looks like it.

Perhaps the last one. I don't understand why it crashes, and I think all we can do is to add null check and assertion to a suspect place in code. David wanted to look closely to find a right place, hope he will come with the patch today.

Comment 4

[alexander :surkov (:asurkov)]

(In reply to comment #3)
> (In reply to comment #1)
> > Alex, is this bug 617300 or bug 498015 or related? Looks like it.
> 
> Perhaps the last one. I don't understand why it crashes, and I think all we can
> do is to add null check and assertion

it doesn't look like null-check crash because aContainer->GetNode() is called earlier in nsDocAccessible::ProcessContentInsertion().

the stack should look
NotificationController::WillRefresh
ContentInsertedNotification::Process
nsDocAccessible::ProcessContentInserted
nsDocAccessible::UpdateTree

however existing stacks miss 2-3 calls. Perhaps we crash in NotificationController::WillRefresh.

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to comment #0)

Thanks Carsten. Any idea why all these stacks seem to be on amd64? Note they seem to stop on January 20th. This might be be a sister crash to fixed bug 627099.

Comment 6

[chris hofmann]

Looks like possibly 2 crashes and a pile of dups from one or two users.

64 bit builds come out on a less frequent pace so it may be a few days before this person updates.

here is a better query with date/time and version number removed to watch for the crash re-appearing.

http://crash-stats.mozilla.com/report/list?signature=nsDocAccessible%3A%3AUpdateTree%28nsAccessible*%2C%20nsIContent*%2C%20int%29

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks that will be helpful and we'll keep an eye on it. Please don't hesitate to ping us or comment here if you notice something.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

Fixed, my guess is bug 627009.