563012 - [SeaMonkey] crashtest and reftest suites hang at startup since "new add-ons manager UI" landing

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Serge Gautherie (:sgautherie)]

Regression timeframe
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b826d7ba5c45&tochange=45a1894f2f9a

See (same) stack in
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1272633062.1272634152.30659.gz&fulltext=1
WINNT 5.2 comm-central-trunk debug test crashtest on 2010/04/30 06:11:02
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1272632867.1272633834.29700.gz&fulltext=1
WINNT 5.2 comm-central-trunk debug test reftest on 2010/04/30 06:07:47
{
Crash reason:  EXCEPTION_ACCESS_VIOLATION
Crash address: 0x0

Thread 13 (crashed)
 0  crashinjectdll.dll!CrashingThread(void *) [crashinjectdll.cpp:254ea07099d2 : 13 + 0x3]
    eip = 0x0123102e   esp = 0x098bffb4   ebp = 0x098bffb8   ebx = 0x00000000
    esi = 0x00000000   edi = 0x00000000   eax = 0x00000000   ecx = 0x098bffb4
    edx = 0x7c8285ec   efl = 0x00010246
    Found by: given as instruction pointer in context
 1  kernel32.dll + 0x24828
    eip = 0x77e64829   esp = 0x098bffc0   ebp = 0x098bffec
    Found by: call frame info

[...]
}
though that's probably one of the other threads which actually triggered the crash...

You can look at Linux and MacOSX stacks too, but I think these stacks can't be trusted atm, can they?

Comment 1

[Serge Gautherie (:sgautherie)]

Hum, maybe bug 561600 is needed to fix this regression?

In any case, it's once again a pity the Core fix landed without SeaMonkey prior warning and proper fix ready :-/

Comment 2

[Justin Wood (:Callek)]

(In reply to comment #1)
> Hum, maybe bug 561600 is needed to fix this regression?
> 
> In any case, it's once again a pity the Core fix landed without SeaMonkey prior
> warning and proper fix ready :-/

Warning actually was here, I offered to start the patch early, and I did tell Mossop that I don't feel right blocking Firefox on our side's fix.

Mossop was actually also very receptive to my Questions along the way.

But my test builds worked fine, so I do suspect that the packaging [and pref] changes will fix this.

Comment 3

[Serge Gautherie (:sgautherie)]

(In reply to comment #2)

Then thanks to Mossop!

Yet, on SeaMonkey side, while it does look like bug 561600 can take the needed time, I do think this bug should be fixed asap...

Comment 4

[Serge Gautherie (:sgautherie)]

Doesn't crash anymore again after bug 562679 backout.

Comment 5

[Dave Townsend [:mossop]]

This is actually a hang of sorts, if the tests doesn't do anything for a long time crashinject forces a crash to get a stack showing what it is up to. The stack doesn't suggest it is stuck in JS so I'd guess some JS exception has happened stopping the main harness from running here.

Comment 6

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) Fully stop packaging xpinstall, missed in bug 561600 [Checkin: Comment 15]

Comment 7

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)
> Created an attachment (id=445242) [details]
> (Av1) Fully stop packaging xpinstall, missed in bug 561600

Ftr, iiuc bug 553169 stopped building xpinstall, though it left the files in the tree.

Comment 8

[Justin Wood (:Callek)]

Comment on attachment 445242 [details] [diff] [review]
(Av1) Fully stop packaging xpinstall, missed in bug 561600
[Checkin: Comment 15]

sorry for missing this in the other bug

Comment 9

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)
> Created an attachment (id=445242) [details]
> (Av1) Fully stop packaging xpinstall, missed in bug 561600

Oh, and TB did +/- the same:
http://hg.mozilla.org/comm-central/rev/4a6a1e8f4389
Update packaged files after the add-on manager landing in mozilla-central. Blanket rs=philor, no bug.

Comment 10

[Justin Wood (:Callek)]

(In reply to comment #9)
> Oh, and TB did +/- the same:
> http://hg.mozilla.org/comm-central/rev/4a6a1e8f4389
> Update packaged files after the add-on manager landing in mozilla-central.
> Blanket rs=philor, no bug.

Unles Philor gave *you* blanket-rs for this type of change, I'm concerned. In IRC he told me that blanket-rs+ was only to Mark (Standard8) for the packaging stuff.

Comment 11

[Phil Ringnalda (:philor)]

While that's true (and it's really just a prettier thing for him to say than "r=bustage" which is what it mostly is and is for), Serge wasn't saying that he checked something in with my rs, he was just quoting way more than you needed to know from the commit message from when Standard8 landed the Tb fixup.

Comment 12

[Justin Wood (:Callek)]

(In reply to comment #9)
> Oh, and TB did +/- the same:

O, erm-sorry. I misread this as "Oh and on TB"... and took the "blanket-rs=philor" as that you committed there. Sorry again for confusion all around.

Comment 13

[Serge Gautherie (:sgautherie)]

Bug 561600 fixed most of it, my patch fixed the remaining (non-blocking) part.
Tinderboxes are not hanging anymore.

Comment 14

[Serge Gautherie (:sgautherie)]

V.Fixed

Comment 15

[Serge Gautherie (:sgautherie)]

Comment on attachment 445242 [details] [diff] [review]
(Av1) Fully stop packaging xpinstall, missed in bug 561600
[Checkin: Comment 15]


http://hg.mozilla.org/comm-central/rev/fe2111ec81ea