bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

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




Disability Access APIs
7 years ago
7 years ago


(Reporter: Tomcat, Assigned: davidb)



Windows 7

Firefox Tracking Flags

(Not tracked)


(crash signature)



7 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


7 years ago
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Hardware: x86 → x86_64

Comment 1

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

Comment 2

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

Comment 3

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

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

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

7 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.

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.
Last Resolved: 7 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.