Closed Bug 471085 Opened 16 years ago Closed 15 years ago

Intermittent hang/crash at end of 'mochitest' suite, triggered by test_videocontrols.html

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Version:
1.9.1 Branch
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.1

People

(Reporter: sgautherie, Assigned: kinetik)

References

(Blocks 1 open bug,
URL
)

Details

(4 keywords, Whiteboard: [fixed1.9.1b99, by blocking bug(s)] )

Attachments

(2 files, 1 obsolete file)

sample of my hang
150.91 KB, text/plain
Details
(Av2-191) Disable test [Backout: See comment 62]
1.13 KB, patch
Dolske
: review+
Details | Diff | Splinter Review 
For some time now, this has been turning our test box RED rather often.

RED log:
{
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1230157540.1230163773.10364.gz
Win2k3 comm-central dep unit test on 2008/12/24 14:25:40

[...]

*** 76292 INFO TEST-PASS | /tests/toolkit/content/tests/widgets/test_videocontrols.html | checking video mute state
*** 76294 INFO Running /tests/uriloader/exthandler/tests/mochitest/test_handlerApps.xhtml...
search "file" not found - skipping.
*** 76295 INFO TEST-PASS | /tests/uriloader/exthandler/tests/mochitest/test_handlerApps.xhtml | webHandler launchWithURI (existing window/tab) started
*** 76296 INFO TEST-PASS | /tests/uriloader/exthandler/tests/mochitest/test_handlerApps.xhtml | webHandler launchWithURI (new window/tab) test started
*** 76297 INFO TEST-PASS | /tests/uriloader/exthandler/tests/mochitest/test_handlerApps.xhtml | localHandler launchWithURI test
search "file" not found - skipping.
*** 76298 INFO TEST-PASS | /tests/uriloader/exthandler/tests/mochitest/test_handlerApps.xhtml | uri passed to web-handler app
*** 76300 INFO Passed: 70539
*** 76301 INFO Failed: 0
*** 76302 INFO Todo:   1496
*** 76303 INFO SimpleTest FINISHED
Document http://localhost:8888/tests/uriloader/exthandler/tests/mochitest/handlerApp.xhtml?uri=webcal%3A%2F%2F127.0.0.1%2Frheeeeet.html loaded successfully

command timed out: 2400 seconds without output, killing pid 46632
SIGKILL failed to kill process
}

Notice the test output _after_ the test suite summary: very unexpected !
Flags: wanted1.9.1?
Afaict, the first occurrence of this bug was
{
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1228452376.1228459082.19700.gz
Win2k3 comm-central dep unit test on 2008/12/04 20:46:16
}
on
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey&maxdate=1228481769

Previous (GREEN) build(s) had
{
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1228448392.1228452808.4304.gz&fulltext=1
Win2k3 comm-central dep unit test on 2008/12/04 19:39:52

*** 75814 INFO TEST-PASS | /tests/toolkit/content/tests/widgets/test_tree_single.xul | mouse-scroll horizontal starting 2 delta 2 eventType MozMousePixelScroll hasPixels false
*** 75816 INFO Running /tests/uriloader/exthandler/tests/mochitest/test_handlerApps.xhtml...
search "file" not found - skipping.
*** 75817 INFO TEST-PASS | /tests/uriloader/exthandler/tests/mochitest/test_handlerApps.xhtml | webHandler launchWithURI (existing window/tab) started
*** 75818 INFO TEST-PASS | /tests/uriloader/exthandler/tests/mochitest/test_handlerApps.xhtml | webHandler launchWithURI (new window/tab) test started
*** 75819 INFO TEST-PASS | /tests/uriloader/exthandler/tests/mochitest/test_handlerApps.xhtml | localHandler launchWithURI test
search "file" not found - skipping.
*** 75820 INFO TEST-PASS | /tests/uriloader/exthandler/tests/mochitest/test_handlerApps.xhtml | uri passed to web-handler app
*** 75822 INFO Passed: 70121
*** 75823 INFO Failed: 0
*** 75824 INFO Todo:   1494
*** 75825 INFO SimpleTest FINISHED
Document http://localhost:8888/tests/uriloader/exthandler/tests/mochitest/handlerApp.xhtml?uri=webcal%3A%2F%2F127.0.0.1%2Frheeeeet.html loaded successfully
SUCCESS: The process with PID 37892 has been terminated.
}

Regression timeframe:
http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?startdate=2008-12-02+15%3A16%3A45&enddate=2008-12-04+20%3A37%3A34

So it would seem the actual cause would rather be related to the added tests: bug 465573 or bug 462116 !

Joel, Justin, if you would not have a clue, I would try disabling (one of) them.
Blocks: 465573, 462116
Keywords: crash, hang, regression
Summary: [SeaMonkey, Windows] Intermittent hang/crash, which could be caused by test_handlerApps.xhtml → [SeaMonkey, Windows] Intermittent hang/crash at end of 'mochitest' suite
(In reply to comment #1)
> Joel, Justin, if you would not have a clue, I would try disabling (one of)
> them.

It happens often enough.
Let's verify whether these tests are actually involved or not:

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/716d2fdc8fb2
(In reply to comment #2)

Last failing build was:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1230243940.1230250121.1845.gz
Win2k3 comm-central dep unit test on 2008/12/25 14:25:40

> http://hg.mozilla.org/releases/mozilla-1.9.1/rev/716d2fdc8fb2

First build after backout was:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1230259432.1230263489.32151.gz
Win2k3 comm-central dep unit test on 2008/12/25 18:43:52

That's now more than 21h without this failure.

Reenabling test_videocontrols.html:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d1fed0726832
(In reply to comment #3)

> Reenabling test_videocontrols.html:
> http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d1fed0726832

First build after this rev ... first failure !
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1230337505.1230343794.4614.gz
Win2k3 comm-central dep unit test on 2008/12/26 16:25:05

Redisabling test_videocontrols.html:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/00013d103cb1
Reenabling the ElementTraversal tests:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b134457cb042
(In reply to comment #4)

That's now more than 2 days without this failure.

Reenabling test_videocontrols.html:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ed9936d2bc8b
Disabling script part of test_videocontrols.html on Windows SeaMonkey:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b83d7c35add7
No longer blocks: 465573
(In reply to comment #5)
> Disabling script part of test_videocontrols.html on Windows SeaMonkey:
> http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b83d7c35add7

First build after this rev ... first failure !
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1230524740.1230530934.13610.gz
Win2k3 comm-central dep unit test on 2008/12/28 20:25:40

So this is triggered by the "HTML" part, probably(!?) the 'video' element (backend).

Justin: helpwanted.
URL: http://mxr.mozilla.org/mozilla1.9.1/s...
Keywords: helpwanted
FWIW, I don't have any idea how the video controls would be involved in this.
(In reply to comment #6)

After that build, there were:
{
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1230524740.1230530934.13610.gz
Win2k3 comm-central dep unit test on 2008/12/28 20:25:40
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1230557140.1230563379.30980.gz
Win2k3 comm-central dep unit test on 2008/12/29 05:25:40
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1230589752.1230595967.7516.gz
Win2k3 comm-central dep unit test on 2008/12/29 14:29:12
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1230595492.1230601744.19255.gz
Win2k3 comm-central dep unit test on 2008/12/29 16:04:52
}
Then no more failure for the past 4,5 days :-)

So this seems to have been fixed sometime after "moz:d1fd2f91887b":
http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?startdate=2008-12-29+16%3A02%3A11&enddate=2009-01-02+14%3A05%3A19
though no checkin seems obvious to me.

Reenabling script part of test_videocontrols.html on Windows SeaMonkey:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/97fb6dbf8295

R.WorksForMe
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: wanted1.9.1?
Keywords: helpwanted
Resolution: --- → WORKSFORME
Summary: [SeaMonkey, Windows] Intermittent hang/crash at end of 'mochitest' suite → [SeaMonkey, Windows] Intermittent hang/crash at end of 'mochitest' suite, triggered by test_videocontrols.html
Target Milestone: --- → mozilla1.9.1b3
Whiteboard: [orange]
This bug has "recently" (= some days...) reappeared, see for example:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1237532106.1237542314.27731.gz
Win2k3 comm-central dep unit test on 2009/03/19 23:55:06
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1237498303.1237511491.5580.gz
Win2k3 comm-central dep unit test on 2009/03/19 14:31:43
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Flags: wanted1.9.1?
This has just been seen on the Firefox 3.5 branch :

Linux mozilla-1.9.1 unit test
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1238138371.1238149811.13005.gz
Summary: [SeaMonkey, Windows] Intermittent hang/crash at end of 'mochitest' suite, triggered by test_videocontrols.html → [Windows] Intermittent hang/crash at end of 'mochitest' suite, triggered by test_videocontrols.html
Status: REOPENED → NEW
OS: Windows Server 2003 → All
Summary: [Windows] Intermittent hang/crash at end of 'mochitest' suite, triggered by test_videocontrols.html → Intermittent hang/crash at end of 'mochitest' suite, triggered by test_videocontrols.html
I'm still a bit suspicious that this could just be an unrelated hang-on-shutdown problem caused by something else, but I guess the test backouts in previous comments do tend to finger <video>.

IIRC, there were some old video bugs (now fixed) about hanging if you quit while a video was playing. Since test_videocontrols.html happens to be the next-to-last mochitest to run, perhaps there's some variant of that still lurking.

Dunno how to diagnose this for sure; someone will probably need to grab a stack or sample from the tinderbox when this happens.
Component: File Handling → Video/Audio
QA Contact: file-handling → video.audio
Flags: wanted1.9.1? → wanted1.9.1+
(Still there:)
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1238612564.1238620116.32097.gzWin2k3 comm-central dep unit test on 2009/04/01 12:02:44
I think I might be seeing this on the Win2k3 VM in my "greener tinderbox" effort.  I couldn't figure out which tests were causing it though.  Will try disabling the video tests there to see what happens.

Is there a good way to grab a stack for you off a release build?  Usually by the time this is detected, the firefox process has been hung at 99% for a long time.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1238631410.1238642720.11887.gz
WINNT 5.2 mozilla-1.9.1 unit test on 2009/04/01 17:16:50
(In reply to comment #11)
> I'm still a bit suspicious that this could just be an unrelated
> hang-on-shutdown problem caused by something else, but I guess the test
> backouts in previous comments do tend to finger <video>.

It may be interesting to look at Windows SeaMonkey box history to find out when this bug reappeared: see comment 9.
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1238660765.1238668609.30438.gz
Win2k3 comm-central dep unit test on 2009/04/02 01:26:05
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1238665390.1238674292.12614.gz
Linux comm-central dep unit test on 2009/04/02 02:43:10
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1238676430.1238683982.7055.gz
Win2k3 comm-central dep unit test on 2009/04/02 05:47:10
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1238678226.1238687031.13632.gz
Linux comm-central dep unit test on 2009/04/02 06:17:06
Attached file sample of my hang — 
I've been quitting the browser with a video showing a lot while working on the video controls, and noticed once in a while I'll get a hang-on-quit. Same cause as the test failures, perhaps? I grabbed a sample, this is a debug build from right after roc landed the media cache (qparent is 0c0a74a303c5).
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1238873167.1238878261.18284.gz
WINNT 5.2 comm-central unit test on 2009/04/04 12:26:07
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1238879330.1238887791.7253.gz
WINNT 5.2 mozilla-1.9.1 unit test on 2009/04/04 14:08:50
Justin, would you rs that I "bypass" this test (again) for SeaMonkey only, ftb?
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1240335244.1240341329.30051.gz
WINNT 5.2 comm-central unit test on 2009/04/21 10:34:04
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1240352303.1240358347.24945.gz
WINNT 5.2 comm-central unit test on 2009/04/21 15:18:23
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1240467929.1240473955.9857.gz
WINNT 5.2 comm-central unit test on 2009/04/22 23:25:29
From a quick look at the call stacks, this looks suspiciously like bug 480063.
Assignee: nobody → kinetik
Depends on: 480063
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1241512180.1241517812.21092.gz
WINNT 5.2 comm-central unit test on 2009/05/05 01:29:40
Attached patch (Av1-191) Disable test (obsolete) — — Splinter Review 
I leave it enabled on Linux as the failure seems rare enough on it.
Attachment #375807 - Flags: review?(dolske)
Comment on attachment 375807 [details] [diff] [review]
(Av1-191) Disable test

I'm not comfortable with disabling this everywhere, given that it seems to only fail on Seamonkey.
Attachment #375807 - Flags: review?(dolske) → review-
(In reply to comment #31)
> it seems to only fail on Seamonkey.

Comment 10, 13, 15 and 23 at least report Firefox (3.5) is affected too!
Of course it seems not as bad for Firefox and if it wants to live with it, I could use an "ifdef MOZ_SUITE ...".
Av1-191, with comment 32 suggestion(s).
Attachment #375807 - Attachment is obsolete: true
Attachment #376402 - Flags: review?(dolske)
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1241960338.1241965596.30633.gz
WINNT 5.2 comm-central unit test on 2009/05/10 05:58:58
Attachment #376402 - Flags: review?(dolske)
Comment on attachment 376402 [details] [diff] [review]
(Av2-191) Disable test
[Backout: See comment 62]

Bug 480063 landed, which should hopefully eliminate the need to disable anything.

I'll let you close this as WFM when you see fit.
(In reply to comment #35)
> Bug 480063 landed, which should hopefully eliminate the need to disable
> anything.

It makes no difference yet: that bug landed on Trunk (ftb) whereas SM boxes are on 1.9.1...
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1242389046.1242394177.3742.gz
WINNT 5.2 comm-central unit test on 2009/05/15 05:04:06
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1242394083.1242399514.18242.gz
WINNT 5.2 comm-central unit test on 2009/05/15 06:28:03
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1242399414.1242403832.28768.gz
WINNT 5.2 comm-central unit test on 2009/05/15 07:56:54
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1242403737.1242408144.4395.gz
WINNT 5.2 comm-central unit test on 2009/05/15 09:08:57
(In reply to comment #38)
> http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242826468.1242832661.17713.gz

This is very unexpected:
this bug is reported on m-1.9.1 only,
and bug 480063 was fixed on m-c.
(In reply to comment #38)
> http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242826468.1242832661.17713.gz

Linux mozilla-central unit test on 2009/05/20 06:34:28
It's possible that I was wrong about it being caused by bug 480063.  Unfortunately we don't have a lot of information about what's going on.  It's also possible that bug 480063 fixed one problem and another problem that caused the same type of failure was introduced to the tree recently.

We really need to get stack traces of a hanging mochitest run.
(In reply to comment #41)
> We really need to get stack traces of a hanging mochitest run.

Just in case, might bug 492956 comment 7 (and previous) be related / help?
Note that case does (or can) crash, so a stack should be available...
Bug 480063 landed on m-1.9.1 on 2009.05.20,
so _hopefully_ this bug should be fixed.

*****

Wow, would this be happening on MacOSX (now, or still very rarely)?

For examples:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1242988154.1242994172.27572.gz
OS X 10.4 comm-central unit test on 2009/05/22 03:29:14
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1243189309.1243194988.12356.gz
OS X 10.4 comm-central unit test on 2009/05/24 11:21:49
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1243226684.1243232319.5675.gz
OS X 10.4 comm-central unit test on 2009/05/24 21:44:44
Whiteboard: [orange] → [See comment 39+43] [orange]
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1243355724.1243361399.16759.gz
OS X 10.4 comm-central unit test on 2009/05/26 09:35:24
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1243378847.1243384694.30065.gz
OS X 10.4 comm-central unit test on 2009/05/26 16:00:47
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1243422510.1243425709.1186.gz
OS X 10.5.2 mozilla-central unit test on 2009/05/27 04:08:30
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1243422700.1243428419.5650.gz
OS X 10.4 comm-central unit test on 2009/05/27 04:11:40
Comment on attachment 376402 [details] [diff] [review]
(Av2-191) Disable test
[Backout: See comment 62]

Afaik,
the main SM/Windows failure has disappeared, but an equivalent main SM/MacOSX failure has appeared;
the +/- seldom report about Linux and/or Firefox seem to be "still" there.

***

Then I would still very much want to land this patch:
to confirm this test is still what triggers this bug,
if so, to give SeaMonkey/MacOSX test box  a break.
Please!

NB: I'll "s/windows/mac/*" before checkin.
Attachment #376402 - Flags: review?(dolske)
So it happens on Linux and on Firefox intermittently? Why only disable it for SeaMonkey OSX then (even though this is where is currently happens most frequently)?
(In reply to comment #50)

As it was +/- previously written:

Firefox (people) doesn't seem to care about this "orange": I'm already loosing way too much time on this months old bug without trying to convince them otherwise.

I thought SeaMonkey could (try and) bear with the (expected) fewer Linux failures then not seeing this failure anymore would tell us it would be time to try and reenable this test.
Currently, I don't know (yet) whether the SeaMonkey/Linux failure went away at the same time as the SeaMonkey/Windows one or not...
Yet, I would agree to disable this test for Linux or even Windows too, if you do want.
Attachment #376402 - Flags: review?(dolske) → review+
Comment on attachment 376402 [details] [diff] [review]
(Av2-191) Disable test
[Backout: See comment 62]

The best guess had been that bug 480063 was going to fix this, it's too bad it didn't. My reluctance to globally disable these tests was because a lot of churn was happening as the RC for 1.9.1 approached, as we'd lose all test coverage for the video controls.

But there's a real problem here, someone needs to reproduce the problem locally and get a stack. If that's apparently easy to do with SeaMonkey, it would be great if you could get this data.

(In reply to comment #51)
> Firefox (people) doesn't seem to care about this "orange"

Yes, yes, all part of the grand anti-SeaMonkey conspiracy! Maybe you shouldn't have waited 2 weeks to ask for review again?
(In reply to comment #52)
> (In reply to comment #51)
> > Firefox (people) doesn't seem to care about this "orange"
> 
> Yes, yes, all part of the grand anti-SeaMonkey conspiracy!

Not really. From what I understand, he meant to say that you guys seem to be ignoring this intermittent orange on Firefox - note that he was replying to my question of why we are excluding this on SeaMonkey only.

And you know, it's a bit frustrating that the way to deal with an apparent failure of Gecko or toolkit code that happens on Firefox as well with a "you debug this for us, please" attitude.
Not because a relatively larger team of partly paid developers is laying burden on a small volunteer team, but because a "the failure might be there but isn't important for us to debug it ourselves" attitude can be poisonous.
(In reply to comment #52)

> The best guess had been that bug 480063 was going to fix this, it's too bad it
> didn't.

It seems that bug may likely be what moved the main failure from SM/Win to SM/Mac, so it would be related at least :-)

> My reluctance to globally disable these tests was because a lot of
> churn was happening as the RC for 1.9.1 approached, as we'd lose all test
> coverage for the video controls.

Now, the same symptom is (still) there but we have to confirm that the cause/trigger is still the same (test)!

> But there's a real problem here, someone needs to reproduce the problem locally
> and get a stack. If that's apparently easy to do with SeaMonkey, it would be
> great if you could get this data.

I am working on bug 494676, so hopefully anyone with a Mac will soon be able to try and do that (much more) easily...

> Yes, yes, all part of the grand anti-SeaMonkey conspiracy!

What?

> Maybe you shouldn't have waited 2 weeks to ask for review again?

Maybe you shouldn't have minused the patch initially??
(Thanks for plusing it now, at last.)


(In reply to comment #53)
> Not really. From what I understand, he meant to say that you guys seem to be
> ignoring this intermittent orange on Firefox - note that he was replying to my
> question of why we are excluding this on SeaMonkey only.

Exactly!
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1243460353.1243466030.18990.gz
OS X 10.4 comm-central unit test on 2009/05/27 14:39:13
Comment on attachment 376402 [details] [diff] [review]
(Av2-191) Disable test
[Backout: See comment 62]


http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a91fe9efc840
(Av3-191) Disable video test(s) on MacOSX SeaMonkey


Fwiw, I don't see this bug in the recent builds of SM and SM-Ports.
Anyway, let's see if this failure occurs again "or" if this patch works around some other failures these boxes have.!.
Attachment #376402 - Attachment description: (Av2-191) Disable test → (Av2-191) Disable test [Checkin: See comment 56]
Whiteboard: [See comment 39+43] [orange] → [test(s) disabled on SM/MacOSX] [See comment 39+43] [orange]
Blocks: SmTestFail
This is still happening (but less?) :-/

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1243560303.1243566036.12767.gz
OS X 10.4 comm-central unit test on 2009/05/28 18:25:03
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1243595286.1243601002.6378.gz
OS X 10.4 comm-central unit test on 2009/05/29 04:08:06
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1243733604.1243739462.29353.gz
OS X 10.4 comm-central unit test on 2009/05/30 18:33:24
Whiteboard: [test(s) disabled on SM/MacOSX] [See comment 39+43] [orange] → [3 tests disabled on SM/MacOSX] [See comment 39+43] [orange]
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1243815292.1243821113.23063.gz
OS X 10.4 comm-central unit test on 2009/05/31 17:14:52
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1243851292.1243857097.12542.gz
OS X 10.4 comm-central unit test on 2009/06/01 03:14:52
Possibly bug 496063 which is an infinite loop that is entered when shutting down while a thread that is seeking. I noticed it when getting a hang exiting a mochitest run.
Depends on: 496063
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1244076115.1244081938.2274.gz
OS X 10.4 comm-central unit test on 2009/06/03 17:41:55

*****

(In reply to comment #60)
> Possibly bug 496063 which is an infinite loop that is entered when shutting

Let's see if this happens again, now that is fixed (too).
Let's hopefully see/confirm this is fixed for good this time:

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ff069347b3e5
(Bv1-191) Re-enable video test(s) on MacOSX SeaMonkey

Undo Av3-191, and sort the test names.
Whiteboard: [3 tests disabled on SM/MacOSX] [See comment 39+43] [orange] → [See comment 62 (39+43)] [orange]
Initial report was fixed in comment 8.

Comment 9 regressions were fixed in comment 43 and comment 61.
Status: NEW → RESOLVED
Closed: 16 years ago → 15 years ago
Keywords: crash → fixed1.9.1
Resolution: --- → FIXED
Whiteboard: [See comment 62 (39+43)] [orange] → [fixed1.9.1rc1, by blocking bug(s)] [orange]
Target Milestone: mozilla1.9.1b3 → mozilla1.9.1
Attachment #376402 - Attachment description: (Av2-191) Disable test [Checkin: See comment 56] → (Av2-191) Disable test [Backout: See comment 62]
Whiteboard: [fixed1.9.1rc1, by blocking bug(s)] [orange] → [fixed1.9.1b99, by blocking bug(s)] [orange]
Depends on: 501034
Depends on: 525296
Why are people (or robots?) starring failures on TryServer?
17th and 20th aren't tryserver, but these should not have been logged in a CLOSED bug that hasn't occurred for over a year.
Whiteboard: [fixed1.9.1b99, by blocking bug(s)] [orange] → [fixed1.9.1b99, by blocking bug(s)]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: