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

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
8 years ago
8 years ago

People

(Reporter: cbook, Assigned: davidb)

Tracking

({crash})

Trunk
x86_64
Windows 7
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

(Reporter)

Description

8 years ago
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

Updated

8 years ago
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Hardware: x86 → x86_64
Alex, is this bug 617300 or bug 498015 or related? Looks like it.
For the record, wasn't me who sent in that crash report, I leave comments. And I haven't seen any crashiness.
(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.
(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.
(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

8 years ago
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
Depends on: 579136
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.
Assignee: nobody → bolterbugz
Fixed, my guess is bug 627009.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsDocAccessible::UpdateTree(nsAccessible*, nsIContent*, int) ]
You need to log in before you can comment on or make changes to this bug.