629137 - Trunk spins (not responding) when launched while Jaws running.

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

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

Tested with a 20 minute old non-debug local trunk build. I hope this is just my machine. Filing in case it persists.

Comment 1

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

 	ntdll.dll!@RtlpLowFragHeapAllocFromContext@8()  + 0x55 bytes	
 	ntdll.dll!_RtlAllocateHeap@12()  + 0xac bytes	
>	msvcr90.dll!malloc(unsigned int size=12)  Line 163 + 0x5f bytes	C
 	mozalloc.dll!moz_xmalloc(unsigned int size=12)  Line 98 + 0x6 bytes	C++
 	xul.dll!nsTArray_base<nsTArrayDefaultAllocator>::EnsureCapacity(unsigned int capacity=1, unsigned int elemSize=4)  Line 77 + 0x10 bytes	C++
 	xul.dll!nsTArray<nsRangeStore *,nsTArrayDefaultAllocator>::AppendElements<nsRangeStore *>(nsRangeStore * const * array=0x00326ec8, unsigned int arrayLen=1)  Line 770 + 0x15 bytes	C++
 	xul.dll!nsAccessibilityService::GetAccessibleByRule(nsINode * aNode=0x09aa3738, nsIWeakReference * aWeakShell=0x09a98218, nsAccessibilityService::EWhatAccToGet aWhatToGet=eGetAccForContainer)  Line 1264 + 0xe bytes	C++
 	xul.dll!nsAccessible::GetParent()  Line 2851 + 0x15 bytes	C++
 	xul.dll!nsRootAccessible::GetContentDocShell(nsIDocShellTreeItem * aStart=0x09a39214)  Line 814 + 0x7 bytes	C++
 	xul.dll!nsRootAccessible::GetContentDocShell(nsIDocShellTreeItem * aStart=0x00000000)  Line 828 + 0xf bytes	C++
 	xul.dll!nsRootAccessible::GetRelationByType(unsigned int aRelationType=10, nsIAccessibleRelation * * aRelation=0x0765daf4)  Line 852 + 0x10 bytes	C++
 	xul.dll!nsAccessible::GetRelations(nsIArray * * aRelations=0x00326fb4)  Line 2376	C++
 	xul.dll!nsAccessible::GetRelationsCount(unsigned int * aCount=0x00000000)  Line 2332	C++
 	xul.dll!nsAccessibleWrap::get_nRelations(long * aNRelations=0x00327004)  Line 1061	C++
 	jhook.dll!15019ae1() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for jhook.dll]	
 	jhook.dll!15019baa() 	
 	jhook.dll!15006ff7() 	
 	jhook.dll!1500da5d() 	
 	KernelBase.dll!_ExpandEnvironmentStringsA@12()  + 0x1be bytes	
 	oleacc.dll!operator delete()  + 0xe bytes	
 	cccccccc()

Comment 2

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

Phew! Problem gone today.

Comment 3

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

And... back.

Comment 4

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

Marking blocking... we need to sort this out.

Comment 5

[Marco Zehe (:MarcoZ)]

This broke between the January 25 and January 26 nightly builds, due to this patch landing:
https://bugzilla.mozilla.org/attachment.cgi?id=504373
Bug 606924, Part3, hanging document concept.

Comment 6

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

Alexander, what are our backout options here? Is it possible to surgically backout that one changeset or is there a domino effect?

Comment 7

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

I realize, ideally we will not have to back out, but I want to know possibilities.

Comment 8

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

Sometimes this hangs my windows debugger. Today I confirmed that the hang doesn't have a consistent stack. Task viewer shows the FF process as very busy, while the jfw process is not. Perhaps this will need to be fixed by code inspection. Please feel free to brain dump ideas about how making document attachment to our a11y tree async might cause this churn.

Comment 9

[alexander :surkov (:asurkov)]

(In reply to comment #6)
> Alexander, what are our backout options here? Is it possible to surgically
> backout that one changeset or is there a domino effect?

I would expect domino effect. Also you should keep in mind no one of latest build is perfect, by backing out you will regress other thing. So all we can do is to "choose" less harm regression if we back out.

Comment 10

[alexander :surkov (:asurkov)]

Bug 626667 fixes it. I really think we shouldn't ship without bug 625653.

Comment 11

[alexander :surkov (:asurkov)]

(In reply to comment #10)
> Bug 626667 fixes it. I really think we shouldn't ship without bug 625653.

part1 of bug 626667 is landed, please check tomorrow nightly. Must be fixed.

Comment 12

[Marco Zehe (:MarcoZ)]

I can confirm that this bug is fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110129 Firefox/4.0b11pre.

Will let David confirm on his end and close the bug.

Comment 13

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

Phew! Confirmed WORKSFORME. Thanks.