Closed Bug 631499 Opened 13 years ago Closed 13 years ago

Crash [@ nsHyperTextAccessible::GetChildOffset(nsAccessible*, int) ]

Categories

(Core :: Disability Access APIs, defect)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla2.0b12

People

(Reporter: scoobidiver, Assigned: fherrera)

References

Details

(Keywords: crash, regression)

Crash Data

It is a new crash signature that first appeared in 4.0b11pre/20110201.

Signature	nsHyperTextAccessible::GetChildOffset(nsAccessible*, int)
UUID	1e2b28ac-aa3e-49e5-9be9-521cc2110202
Time 	2011-02-02 21:07:24.797591
Uptime	28707
Last Crash	28708 seconds (8.0 hours) before submission
Install Age	64845 seconds (18.0 hours) since version was first installed.
Product	Firefox
Version	4.0b11pre
Build ID	20110201030339
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 6
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x0
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0612, AdapterDriverVersion: 8.17.12.5896

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsHyperTextAccessible::GetChildOffset 	obj-firefox/dist/include/nsHyperTextAccessible.h:223
1 	xul.dll 	TextUpdater::FireEvent 	accessible/src/base/NotificationController.cpp:838
2 	xul.dll 	TextUpdater::Run 	accessible/src/base/NotificationController.cpp:671
3 	xul.dll 	NotificationController::TextEnumerator 	accessible/src/base/NotificationController.cpp:930
4 	xul.dll 	nsTHashtable<nsPtrHashKey<nsFontFaceLoader> >::s_EnumStub 	obj-firefox/dist/include/nsTHashtable.h:420
5 	xul.dll 	PL_DHashTableEnumerate 	obj-firefox/xpcom/build/pldhash.c:754
6 	xul.dll 	nsTHashtable<NotificationController::nsCOMPtrHashKey<nsIContent> >::EnumerateEntries 	obj-firefox/dist/include/nsTHashtable.h:241
7 	xul.dll 	NotificationController::WillRefresh 	accessible/src/base/NotificationController.cpp:247
8 	xul.dll 	nsRefreshDriver::Notify 	layout/base/nsRefreshDriver.cpp:254
9 	xul.dll 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:428
10 	xul.dll 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:517
11 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
12 	xul.dll 	nsThread::PutEvent 	xpcom/threads/nsThread.cpp:393
13 	xul.dll 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:250
14 	xul.dll 	nsThread::Shutdown 	xpcom/threads/nsThread.cpp:492
15 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
16 	xul.dll 	nsProxyObjectCallInfo::Run 	xpcom/proxy/src/nsProxyEvent.cpp:181
17 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
18 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
19 	xul.dll 	xul.dll@0xb2ca5b 	
20 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
21 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:202
22 	mozcrt19.dll 	_VEC_memzero 	
23 	xul.dll 	xul.dll@0x35c21d 	
24 	firefox.exe 	firefox.exe@0x1bb7 	
25 	ntdll.dll 	WinSqmSetIfMaxDWORD 	
26 	ntdll.dll 	_RtlUserThreadStart 	
27 	firefox.exe 	firefox.exe@0x186f 	
28 	firefox.exe 	firefox.exe@0x186f 	

The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ba3fe7ee56b9&tochange=8b5cb26bbb10

More reports at:
https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsHyperTextAccessible%3A%3AGetChildOffset%28nsAccessible*%2C%20int%29
This could be related to the mOffsets problem fixed on bug #630841. Does it make sense?
Yeah there are no new crashes right?
> Yeah there are no new crashes right?
Because of the release of Beta 11, all Minefield automatic updates are disabled. So 4.0b11pre/20110201 must be considered as the "latest" version.
Note that I was updated to the 20110202 build on Wednesday. And if this doesn't appear in b11 when it's publicly available, this bug can be fixed, because it'll be fixed by the crash fix for bug 630841.
It also make sense to have different crashes/signatures on linux and windows.

When a nshypertext accessible is removed we fire delete text event for the parent and the atk bridge calls automatically GetText to retrive information about deleted text, and the it crashes there trying to access non-existent childs. In windows we don't have this automatic GetText call, so it's normal it crashes on the next update.
> And if this doesn't appear in b11 when it's publicly available, this bug can be 
> fixed
It happens in 4.0b11 and is currently #26 top crasher.
Assignee: nobody → fherrera
It is now #11 top crasher in 4.0b11.

bug 630841 was fixed in 4.0b12pre/20110204.
Until now, the latest crash is in 4.0b12pre/20110207: bp-7c000d6c-1381-40ec-a7c7-14f6e2110210.
I sounds it should have been fixed by bug 626660.
As per IRC:

fer: 20110207030345 is the latest crashing build
fer: patch on 626660 landed on 7th...

Should be fixed but let's check again after beta12 hits its audience.
(In reply to comment #9)
> Should be fixed but let's check again after beta12 hits its audience.

Let's reopen it instead if it's still presented, I'm pretty confident it's fixed by bug 626660 and actually a dupe of bug 631213 but has a different signature due to some reason. Stack points to http://hg.mozilla.org/mozilla-central/annotate/8b5cb26bbb10/accessible/src/html/nsHyperTextAccessible.h#l223. That means the pointer is not valid.
Status: NEW → RESOLVED
Closed: 13 years ago
Depends on: 626660
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b12
Crash Signature: [@ nsHyperTextAccessible::GetChildOffset(nsAccessible*, int) ]
You need to log in before you can comment on or make changes to this bug.