Closed Bug 550819 Opened 14 years ago Closed 14 years ago

A11y test suite crash [@ nsTArray_base::Length]

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: davidb, Assigned: surkov)

References

Details

Attachments

(1 file)

patch
16.25 KB, patch
MarcoZ
: review+
davidb
: review+
Details | Diff | Splinter Review 
Had a crash during our a11y test suite run on:
WINNT 5.2 mozilla-central debug test mochitest-other Started 21:38, finished 22:03
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1268015881.1268017337.9647.gz&fulltext=1#err0

 0  xul.dll!nsTArray_base::Length() [nsTArray.h:ee9dd725d8ea : 66 + 0x5]
    eip = 0x1000387c   esp = 0x0012c82c   ebp = 0x0012c830   ebx = 0x00000001
    esi = 0x00000c00   edi = 0x00000000   eax = 0x0775144c   ecx = 0xdddddddd
    edx = 0x019a3e8c   efl = 0x00210202
    Found by: given as instruction pointer in context
 1  xul.dll!nsTArray<nsRefPtr<nsAccessible> >::Clear() [nsTArray.h:ee9dd725d8ea : 707 + 0x7]
    eip = 0x10eed72f   esp = 0x0012c838   ebp = 0x0012c83c
    Found by: call frame info
 2  xul.dll!nsAccessible::InvalidateChildren() [nsAccessible.cpp:ee9dd725d8ea : 2891 + 0xa]
    eip = 0x10eec2c4   esp = 0x0012c844   ebp = 0x0012c854
    Found by: call frame info
 3  xul.dll!nsAccessible::Shutdown() [nsAccessible.cpp:ee9dd725d8ea : 492 + 0x1d]
    eip = 0x10ee4346   esp = 0x0012c85c   ebp = 0x0012c864
    Found by: call frame info
 4  xul.dll!ClearCacheEntry [nsAccessNode.cpp:ee9dd725d8ea : 718 + 0x17]
    eip = 0x10ec9dc6   esp = 0x0012c86c   ebp = 0x0012c870
    Found by: call frame info
 5  xul.dll!nsBaseHashtable<nsPtrHashKey<void const >,nsCOMPtr<nsAccessNode>,nsAccessNode *>::s_EnumStub(PLDHashTable *,PLDHashEntryHdr *,unsigned int,void *) [nsBaseHashtable.h:ee9dd725d8ea : 346 + 0x1d]
    eip = 0x10eca5d0   esp = 0x0012c878   ebp = 0x0012c88c
    Found by: call frame info
 6  xul.dll!PL_DHashTableEnumerate [pldhash.c:ee9dd725d8ea : 754 + 0x18]
    eip = 0x11005468   esp = 0x0012c894   ebp = 0x0012c8d4
    Found by: call frame info
 7  xul.dll!nsBaseHashtable<nsPtrHashKey<void const >,nsCOMPtr<nsAccessNode>,nsAccessNode *>::Enumerate(PLDHashOperator (*)(void const *,nsCOMPtr<nsAccessNode> &,void *),void *) [nsBaseHashtable.h:ee9dd725d8ea : 221 + 0x11]
    eip = 0x10eca2d2   esp = 0x0012c8dc   ebp = 0x0012c8f4
    Found by: call frame info
 8  xul.dll!nsAccessNode::ClearCache(nsInterfaceHashtable<nsPtrHashKey<void const >,nsAccessNode> &) [nsAccessNode.cpp:ee9dd725d8ea : 726 + 0xe]
    eip = 0x10ec9d62   esp = 0x0012c8fc   ebp = 0x0012c904
    Found by: call frame info
 9  xul.dll!nsDocAccessible::Shutdown() [nsDocAccessible.cpp:ee9dd725d8ea : 650 + 0xe]
    eip = 0x10f0c174   esp = 0x0012c90c   ebp = 0x0012c924
    Found by: call frame info
10  xul.dll!nsRootAccessible::HandleEventWithTarget(nsIDOMEvent *,nsIDOMNode *) [nsRootAccessible.cpp:ee9dd725d8ea : 628 + 0x23]
    eip = 0x10f3cd27   esp = 0x0012c92c   ebp = 0x0012cc9c
    Found by: call frame info
11  xul.dll!nsRootAccessible::HandleEvent(nsIDOMEvent *) [nsRootAccessible.cpp:ee9dd725d8ea : 589 + 0x1a]
    eip = 0x10f3cb85   esp = 0x0012cca4   ebp = 0x0012ccbc
    Found by: call frame info
12  xul.dll!nsEventListenerManager::HandleEventSubType(nsListenerStruct *,nsIDOMEventListener *,nsIDOMEvent *,nsPIDOMEventTarget *,unsigned int,nsCxPusher *) [nsEventListenerManager.cpp:ee9dd725d8ea : 1082 + 0x11]
    eip = 0x103b02cf   esp = 0x0012ccc4   ebp = 0x0012ce70
    Found by: call frame info
13  xul.dll!nsEventListenerManager::HandleEvent(nsPresContext *,nsEvent *,nsIDOMEvent * *,nsPIDOMEventTarget *,unsigned int,nsEventStatus *,nsCxPusher *) [nsEventListenerManager.cpp:ee9dd725d8ea : 1198 + 0x26]
    eip = 0x103b0739   esp = 0x0012ce78   ebp = 0x0012cee0
    Found by: call frame info
14  xul.dll!nsEventTargetChainItem::HandleEvent(nsEventChainPostVisitor &,unsigned int,int,nsCxPusher *) [nsEventDispatcher.cpp:ee9dd725d8ea : 201 + 0x47]
    eip = 0x1050dbc9   esp = 0x0012cee8   ebp = 0x0012cf18
    Found by: call frame info
15  xul.dll!nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor &,unsigned int,nsDispatchingCallback *,int,nsCxPusher *) [nsEventDispatcher.cpp:ee9dd725d8ea : 296 + 0x3d]
    eip = 0x1050d7d9   esp = 0x0012cf20   ebp = 0x0012cf58
    Found by: call frame info
16  xul.dll!nsEventDispatcher::Dispatch(nsISupports *,nsPresContext *,nsEvent *,nsIDOMEvent *,nsEventStatus *,nsDispatchingCallback *,nsCOMArray<nsPIDOMEventTarget> *) [nsEventDispatcher.cpp:ee9dd725d8ea : 601 + 0x1d]
    eip = 0x1050e56e   esp = 0x0012cf60   ebp = 0x0012d084
    Found by: call frame info
17  xul.dll!nsEventDispatcher::DispatchDOMEvent(nsISupports *,nsEvent *,nsIDOMEvent *,nsPresContext *,nsEventStatus *) [nsEventDispatcher.cpp:ee9dd725d8ea : 664 + 0x1c]
    eip = 0x1050ecea   esp = 0x0012d08c   ebp = 0x0012d0d4
    Found by: call frame info
18  xul.dll!nsDocument::DispatchPageTransition(nsPIDOMEventTarget *,nsAString_internal const &,int) [nsDocument.cpp:ee9dd725d8ea : 7154 + 0x17]
    eip = 0x103ea792   esp = 0x0012d0dc   ebp = 0x0012d128
    Found by: call frame info
19  xul.dll!nsDocument::OnPageHide(int,nsIDOMEventTarget *) [nsDocument.cpp:ee9dd725d8ea : 7260 + 0x24]
    eip = 0x103eab49   esp = 0x0012d130   ebp = 0x0012d17c
    Found by: call frame info
20  xul.dll!DocumentViewerImpl::PageHide(int) [nsDocumentViewer.cpp:ee9dd725d8ea : 1263 + 0x29]
    eip = 0x103b62f3   esp = 0x0012d184   ebp = 0x0012d1d0
    Found by: call frame info
21  xul.dll!nsDocShell::FirePageHideNotification(int) [nsDocShell.cpp:ee9dd725d8ea : 1461 + 0x22]
    eip = 0x10b96437   esp = 0x0012d1d8   ebp = 0x0012d228
    Found by: call frame info
This happened on the next run as well:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1268035779.1268037468.17464.gz
WINNT 5.2 mozilla-central debug test mochitest-other on 2010/03/07 18:38:01
s: win32-slave16

Is it possible it could be connected to the checkin of bug 548291?
Oops, sorry, copied from wrong log. Comment #1 was actually about:

WINNT 5.2 mozilla-central debug test mochitest-other on 2010/03/08 00:09:39
s: mw32-ix-slave04

(The link is correct.)
(In reply to comment #1)
> Is it possible it could be connected to the checkin of bug 548291?

Seems likely, let's wait for one more run . Note I haven't seen this fail on the Windows opt test machine (nor on try).
This is happening consistently on windows debug. I'll probably back out. Waiting for my local build to finish to see if I can recreate on my machine.
Note there is similarity with stack on bug 549715.
Could be mChildren has been already cycle collected when you try to clear it on ::Shutdown()? it is part of the collection.
(In reply to comment #6)
> Could be mChildren has been already cycle collected when you try to clear it on
> ::Shutdown()? it is part of the collection.

Seems possible yes.
Ah, I think I found the problem. I'll post a new patch when I have a bit of time, over on bug 548291.
(In reply to comment #9)
> Ah, I think I found the problem. I'll post a new patch when I have a bit of
> time, over on bug 548291.

I retract.
Note this crash exists even without the source code changes from my original push (on bug 548291). That is: the tests will crash trunk on windows.
Attached patch patch — — Splinter Review 
1) more area and image map cleanup
2) do not create temporary imagemap accessible when area accessible is created so that area accessibles have correct parent what fix the crash in the end
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #437519 - Flags: review?(marco.zehe)
Attachment #437519 - Flags: review?(bolterbugz)
Comment on attachment 437519 [details] [diff] [review]
patch

Seeing no difference between regular nightly and try-server in rendering image maps, also no crashes. r=me for the manual testing aspect. I also browsed the patch and didn't see anything that looked out of place.
Attachment #437519 - Flags: review?(marco.zehe) → review+
Comment on attachment 437519 [details] [diff] [review]
patch

r=me, thanks! You have put my thoughts into code!

>+    // Not the main content for this frame. This happens because <area>
>+    // elements return the image frame as their primary frame. The main content
>+    // for the image frame is the image content.
>+    return GetAreaAccessible(weakFrame.GetFrame(), aNode, aWeakShell);

Nit: Maybe comment that this returns null if not an nsIImageFrame.
Attachment #437519 - Flags: review?(bolterbugz) → review+
(In reply to comment #15)
> (From update of attachment 437519 [details] [diff] [review])
> r=me, thanks! You have put my thoughts into code!

yw! if I could read your thoughts I would find a problem much quicker :)

> >+    // Not the main content for this frame. This happens because <area>
> >+    // elements return the image frame as their primary frame. The main content
> >+    // for the image frame is the image content.
> >+    return GetAreaAccessible(weakFrame.GetFrame(), aNode, aWeakShell);
> 
> Nit: Maybe comment that this returns null if not an nsIImageFrame.

sure
(In reply to comment #16)
> (In reply to comment #15)
> > (From update of attachment 437519 [details] [diff] [review] [details])
> > r=me, thanks! You have put my thoughts into code!
> 
> yw! if I could read your thoughts I would find a problem much quicker :)

You trust my thoughts more than I do :)
(In reply to comment #14)
> (From update of attachment 437519 [details] [diff] [review])
> Seeing no difference between regular nightly and try-server in rendering image
> maps, also no crashes. r=me for the manual testing aspect. I also browsed the
> patch and didn't see anything that looked out of place.

Oh hmmm so we haven't confirmed this fixes the crash?
(In reply to comment #18)

> Oh hmmm so we haven't confirmed this fixes the crash?

I do :) It doesn't crash for me any more. It makes sense if you'll try as well.
Ha! I mid-air collided.

Was: I wanted to confirm this fix tonight but my windows vm is too painful (need more RAM). I can certainly check on Friday (I'm away tomorrow). Either way I'm happy with the patch.

Now: Good enough! Thanks!
landed on 1.9.3 - http://hg.mozilla.org/mozilla-central/rev/d294c76984c6
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
For the record: I never experienced any crash with image maps, the first I heard of this crash was when David wanted to land bug 548291. I could only confirm that the a11y worked as before.
I was able to reproduce the crash with David's mochitests only from bug bug 548291. I think it might be a crash that's hard to get in real life.
we believe so ;-)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: