Closed Bug 629137 Opened 12 years ago Closed 12 years ago

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

Categories

(Core :: Disability Access APIs, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
blocking2.0 --- final+

People

(Reporter: davidb, Assigned: davidb)

References

Details

(Whiteboard: [hardblocker])

Tested with a 20 minute old non-debug local trunk build. I hope this is just my machine. Filing in case it persists.
 	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()
Status: NEW → UNCONFIRMED
Ever confirmed: false
Phew! Problem gone today.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
And... back.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---
Marking blocking... we need to sort this out.
blocking2.0: --- → final+
Whiteboard: [soft/hard pending]
Whiteboard: [soft/hard pending] → [hardblocker][regression window wanted]
Assignee: nobody → bolterbugz
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.
Whiteboard: [hardblocker][regression window wanted] → [hardblocker]
Summary: Trunk spins (not responding) when launched while Jaws 11 running. → Trunk spins (not responding) when launched while Jaws running.
Alexander, what are our backout options here? Is it possible to surgically backout that one changeset or is there a domino effect?
I realize, ideally we will not have to back out, but I want to know possibilities.
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.
(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.
Bug 626667 fixes it. I really think we shouldn't ship without bug 625653.
Depends on: 626667
(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.
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.
Phew! Confirmed WORKSFORME. Thanks.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.