629695 - Crash when running Thunderbird MozMill message header tests [@nsINode::HasFlag]

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Reader UI, defect)

Description

[Mark Banner (:standard8)]

Since one of the following check-ins, we're seeing crashes on the Thunderbird MozMill tests:

http://hg.mozilla.org/mozilla-central/rev/3cbf026c2ce2 (bug 627693)
http://hg.mozilla.org/mozilla-central/rev/e21c1c2813ad (bug 611986)
http://hg.mozilla.org/mozilla-central/rev/51188908033f (bug 626049)

Link to full log:

http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird/1296229634.1296230194.2565.gz&fulltext=1#err0

Top of stack:

 0  xul.dll!nsINode::HasFlag(unsigned long) [nsINode.h:0f313f7b192e : 853 + 0x0]
    eip = 0x101e0b1c   esp = 0x0012b2b8   ebp = 0x0012b304   ebx = 0x05cef080
    esi = 0x058d2d50   edi = 0x006e0040   eax = 0x00610040   ecx = 0x006e0040
    edx = 0x05cef080   efl = 0x00010202
    Found by: given as instruction pointer in context
 1  xul.dll!NotificationController::TextEnumerator(nsPtrHashKey<nsIContent> *,void *) [NotificationController.cpp:37bf42a252ef : 601 + 0xb]
    eip = 0x106b69b3   esp = 0x0012b2bc   ebp = 0x0012b304
    Found by: call frame info
 2  xul.dll!nsTHashtable<nsPtrHashKey<nsSMILTimeContainer> >::s_EnumStub(PLDHashTable *,PLDHashEntryHdr *,unsigned int,void *) [nsTHashtable.h:0f313f7b192e : 420 + 0xc]
    eip = 0x10408039   esp = 0x0012b37c   ebp = 0x0012b3b4   ebx = 0x058beaf0
    Found by: call frame info
 3  xul.dll!PL_DHashTableEnumerate [pldhash.c:0f313f7b192e : 754 + 0xa]
    eip = 0x100f7641   esp = 0x0012b388   ebp = 0x0012b3b4
    Found by: call frame info
 4  xul.dll!nsTHashtable<nsPtrHashKey<void const > >::EnumerateEntries(PLDHashOperator (*)(nsPtrHashKey<void const > *,void *),void *) [nsTHashtable.h:0f313f7b192e : 241 + 0xe]
    eip = 0x103b8dda   esp = 0x0012b3bc   ebp = 0x0012b3d0   ebx = 0x058d2d50
    Found by: call frame info
 5  xul.dll!NotificationController::WillRefresh(mozilla::TimeStamp) [NotificationController.cpp:37bf42a252ef : 247 + 0x11]
    eip = 0x106b6c9e   esp = 0x0012b3d8   ebp = 0x0012b404
    Found by: call frame info
 6  xul.dll!nsRefreshDriver::Notify(nsITimer *) [nsRefreshDriver.cpp:37bf42a252ef : 254 + 0xf]
    eip = 0x10210325   esp = 0x0012b40c   ebp = 0x0012b438   ebx = 0x00000000
    Found by: call frame info
 7  xul.dll!nsTimerImpl::Fire() [nsTimerImpl.cpp:37bf42a252ef : 428 + 0x6]
    eip = 0x108a18a9   esp = 0x0012b4b0   ebp = 0x0012b4d4   ebx = 0x00000001
    Found by: call frame info
 8  xul.dll!nsTimerEvent::Run() [nsTimerImpl.cpp:37bf42a252ef : 517 + 0x6]
    eip = 0x108a1a17   esp = 0x0012b4dc   ebp = 0x0012b50c   ebx = 0x00000000
    Found by: call frame info
 9  xul.dll!nsThread::ProcessNextEvent(int,int *) [nsThread.cpp:37bf42a252ef : 633 + 0x5]
    eip = 0x108a2f1a   esp = 0x0012b4e4   ebp = 0x0012b50c
    Found by: call frame info

Comment 1

[Mark Banner (:standard8)]

I've pushed several patches to Thunderbird try server to see if I can narrow down which bug is causing the issue.

Comment 2

[Jacek Caban]

Thanks. I don't see how any of these patches could cause this crash. Let's see that try server will find.

Comment 3

[Mark Banner (:standard8)]

FYI I think if any of the ones I suggested, then it may be http://hg.mozilla.org/mozilla-central/rev/e21c1c2813ad (bug 611986) that is the issue.

However don't take that as a certainty yet as we've got failures with another test in the same sub-section and I need to resolve those to make sure I get a clear result. Hopefully I'll be able to do that today or tomorrow.

Comment 4

[rsx11m]

Is this resolved? I still see the test_a11y_attrs test failure on WINNT 5.2 comm-central test mozmill, which was there before, but no longer crashing.

Comment 5

[Mark Banner (:standard8)]

(In reply to comment #4)
> Is this resolved? I still see the test_a11y_attrs test failure on WINNT 5.2
> comm-central test mozmill, which was there before, but no longer crashing.

No. There are still occasional crashes. I'm also not sure if the almost-permanent test_a11y_attrs failure is actually preventing the tests hitting the crash point seen in this bug. I'm currently looking at resolving that failure, then we'll be in a better position to assess this crash.

Comment 6

[Mark Banner (:standard8)]

I've not seen this since we fixed the other failure. So either something else fixed it or it was a side-effect of that failure. Nothing really to investigate now.