Closed Bug 643906 Opened 9 years ago Closed 9 years ago

Firefox 4.0 Crash Report [@ nsAccessible::AsHyperText() ]

Categories

(Core :: Disability Access APIs, defect, critical)

All
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla5
Tracking Status
blocking2.0 --- .x+

People

(Reporter: mats, Assigned: surkov)

References

()

Details

(Keywords: crash, Whiteboard: [safe nullcheck])

Crash Data

Attachments

(1 file, 1 obsolete file)

Currently at #148 in the top crash list for Firefox 4, which seems
relatively high for an a11y crash.  There were 972 crash reports
in the past two week period, all on Windows, all in Gecko 2.0

Five crash reports have a user comment, three of which appears
to have Chinese text.  One URL was mentioned:
http://blog.sina.com.cn/s/blog_4939384201018aar.html

bp-1a57a03e-e9ae-41bd-bd4a-372fa2110322

nsAccessible::AsHyperText	obj-firefox/dist/include/nsHyperTextAccessible.h:440
TextUpdater::DoUpdate	accessible/src/base/TextUpdater.cpp:75
TextUpdater::Run	accessible/src/base/TextUpdater.cpp:64
NotificationController::TextEnumerator	accessible/src/base/NotificationController.cpp:650
nsTHashtable<nsPtrHashKey<nsSMILTimeValueSpec> >::s_EnumStub	obj-firefox/dist/include/nsTHashtable.h:420
PL_DHashTableEnumerate	obj-firefox/xpcom/build/pldhash.c:754
nsTHashtable<NotificationController::nsCOMPtrHashKey<nsIContent> >::EnumerateEntries	obj-firefox/dist/include/nsTHashtable.h:241
NotificationController::WillRefresh	accessible/src/base/NotificationController.cpp:249
nsRefreshDriver::Notify	layout/base/nsRefreshDriver.cpp:254
nsTimerImpl::Fire	xpcom/threads/nsTimerImpl.cpp:428
nsTimerEvent::Run	xpcom/threads/nsTimerImpl.cpp:517
nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:633
mozilla::ipc::MessagePump::Run	ipc/glue/MessagePump.cpp:110
xul.dll@0xb367c7	
MessageLoop::RunInternal	ipc/chromium/src/base/message_loop.cc:219
MessageLoop::RunHandler	ipc/chromium/src/base/message_loop.cc:202
_VEC_memzero	
xul.dll@0x35d7cd	
firefox.exe@0x1bb7	
LdrpAppendToForwarderList	
_RtlUserThreadStart	
firefox.exe@0x186f	
firefox.exe@0x186f
All crashes are EXCEPTION_ACCESS_VIOLATION_READ at 0x38.
I'm guessing that is the offset of 'mFlags' and that 'parent' is null here:
http://hg.mozilla.org/releases/mozilla-2.0/annotate/6be9e31d01b4/accessible/src/base/TextUpdater.cpp#l75
Attached patch patch (obsolete) — Splinter Review
can't reproduce it, no idea how we can get bad tree leading to crash, just null check.
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #521098 - Flags: review?(bolterbugz)
Attachment #521098 - Flags: approval2.0?
(In reply to comment #3)
> Any wild ideas?

the tree is broken, why - dunno, no idea. Add assertion and hope to get a testcase in future.
it should be blocker request rather than approval I guess.
blocking2.0: --- → ?
Attachment #521098 - Flags: approval2.0?
Comment on attachment 521098 [details] [diff] [review]
patch

OK the patch is safe, but this is a concern we need to sort out right? I guess at least we'll hit a debug break potentially.
Attachment #521098 - Flags: review?(bolterbugz) → review+
Whiteboard: [d?][how do we mark safe bug fixes for .x?]
blocking2.0: ? → .x+
Whiteboard: [d?][how do we mark safe bug fixes for .x?] → [safe nullcheck]
(In reply to comment #6)
> Comment on attachment 521098 [details] [diff] [review]
> patch
> 
> OK the patch is safe, but this is a concern we need to sort out right? I guess
> at least we'll hit a debug break potentially.

we should. I hope either to find a reliable steps to trigger an assertion in the wild or get in mochitests by chance.
Attached patch patch to landSplinter Review
Attachment #521098 - Attachment is obsolete: true
Whiteboard: [safe nullcheck] → [safe nullcheck][fx4-rc-ridealong][has reviewed patch]
A Debian user encountered this crash when removing new line characters with backspace in a text field. (In case that helps to create a testcase)
(In reply to comment #9)
> A Debian user encountered this crash when removing new line characters with
> backspace in a text field. (In case that helps to create a testcase)

I am using commercial web application to correct English in Academic writing. This bug is 100% reproducible with any text edited in the text entry. Usually it happens on the words that are marked to be corrected (red underline) and using backspace to remove new line in front of them leads to crash from which full backtrace I reported.

This is the worst blocker bug for me, since I cannot use this application.
If You want me to perform additional checks or something that might help to solve this issue, just contact me.
landed - http://hg.mozilla.org/mozilla-central/rev/7be1c6040610
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [safe nullcheck][fx4-rc-ridealong][has reviewed patch] → [safe nullcheck]
Target Milestone: --- → mozilla2.2
(In reply to comment #9)
> A Debian user encountered this crash when removing new line characters with
> backspace in a text field. (In case that helps to create a testcase)

Can't reproduce it on textarea.

(In reply to comment #10)

> I am using commercial web application to correct English in Academic writing.

Can you try to extract a testcase from it please?
I tried latest iceweasel which was uploaded recently. I cannot reproduce this bug anymore. If I don't replay till Wednesday 30 March, it means I have no more problems.
(latest iceweasel including the patch from this bug)
I could not reproduce it with

iceweasel 4.0-3
libmozjs4d 2.0-3
xulrunner 2.0-3

so looks like fixed. Thank You
Sorry I'm very clear about your process, but if this bug has been marked as "RESOLVED", why I was still encountering this bug over and over again?

The very recent ones are:    
bp-434636b8-b302-412e-807d-6aad02110330 2011/3/313:26
bp-98584635-4d57-407b-a9a4-04b6c2110329 2011/3/304:15
bp-8ee39842-8ae0-46a0-92c9-959fa2110328 2011/3/290:34
bp-851b7eb9-7ae4-440c-873b-bfd2a2110327 2011/3/282:24

It only happens when browsing/posting comments on this page:
http://oreno.imouto.org/comment
(In reply to comment #16)
> Sorry I'm very clear about your process, but if this bug has been marked as
> "RESOLVED", why I was still encountering this bug over and over again?
> 
> The very recent ones are:    

They are targeted to Firefox 4. The fix is landed on trunk. We'll make sure to deliver this fix when Firefox 4.x version is shipped.
(In reply to comment #17)
> (In reply to comment #16)
> > Sorry I'm very clear about your process, but if this bug has been marked as
> > "RESOLVED", why I was still encountering this bug over and over again?
> > 
> > The very recent ones are:    
> 
> They are targeted to Firefox 4. The fix is landed on trunk. We'll make sure to
> deliver this fix when Firefox 4.x version is shipped.

Thanks.

(Btw I missed one "not" in first sentence :P)
AFAICT, this did not make 4.0.1 :(
(In reply to comment #19)
> AFAICT, this did not make 4.0.1 :(

Unfortunately no a11y bugs were taken into fx 4.0.1. All these fixes will be available in fx 5.
Crash Signature: [@ nsAccessible::AsHyperText() ]
You need to log in before you can comment on or make changes to this bug.