Closed Bug 525635 Opened 15 years ago Closed 13 years ago

browser_NetworkPrioritizer.js times out constantly on 1.9.2

Categories

(Firefox :: General, defect)

3.6 Branch
All
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mak, Assigned: zpao)

References

(Depends on 1 open bug)

Details

(Whiteboard: [test disabled])

Attachments

(1 file)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1256979895.1256986981.32747.gz
Linux mozilla-central test debug everythingelse on 2009/10/31 02:04:55

TEST-PASS | chrome://mochikit/content/browser/browser/base/content/test/browser_NetworkPrioritizer.js | Tab had expected priority
TEST-PASS | chrome://mochikit/content/browser/browser/base/content/test/browser_NetworkPrioritizer.js | Tab had expected priority
pldhash: for the table at address 0x8eb7ff8, the given entrySize of 48 probably favors chaining over double hashing.
++DOCSHELL 0x8eb7f90 == 10
++DOMWINDOW == 19 (0x93b5640) [serial = 19] [outer = (nil)]
++DOMWINDOW == 20 (0x919e528) [serial = 20] [outer = 0x93b5610]
WARNING: NS_ENSURE_TRUE(mutableURL) failed: file /builds/moz2_slave/mozilla-central-linux-debug/build/content/xul/templates/src/nsXULContentUtils.cpp, line 333
pldhash: for the table at address 0x9544240, the given entrySize of 48 probably favors chaining over double hashing.
++DOCSHELL 0x95441d8 == 11
++DOMWINDOW == 21 (0x9544a38) [serial = 21] [outer = (nil)]
pldhash: for the table at address 0x9557d78, the given entrySize of 48 probably favors chaining over double hashing.
++DOCSHELL 0x9557d10 == 12
++DOMWINDOW == 22 (0x95584e8) [serial = 22] [outer = (nil)]
pldhash: for the table at address 0x958e6b0, the given entrySize of 48 probably favors chaining over double hashing.
++DOCSHELL 0x958e648 == 13
++DOMWINDOW == 23 (0x958ef38) [serial = 23] [outer = (nil)]
WARNING: Subdocument container has no frame: file /builds/moz2_slave/mozilla-central-linux-debug/build/layout/base/nsDocumentViewer.cpp, line 2373
++DOMWINDOW == 24 (0x96135d0) [serial = 24] [outer = 0x9544a08]
WARNING: Subdocument container has no frame: file /builds/moz2_slave/mozilla-central-linux-debug/build/layout/base/nsDocumentViewer.cpp, line 2373
++DOMWINDOW == 25 (0x9615cb0) [serial = 25] [outer = 0x95584b8]
++DOMWINDOW == 26 (0x961c900) [serial = 26] [outer = 0x958ef08]
WARNING: NS_ENSURE_TRUE(mMutable) failed: file /builds/moz2_slave/mozilla-central-linux-debug/build/netwerk/base/src/nsSimpleURI.cpp, line 224
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file /builds/moz2_slave/mozilla-central-linux-debug/build/chrome/src/nsChromeRegistry.cpp, line 1351
++DOMWINDOW == 27 (0x96710c0) [serial = 27] [outer = 0x958ef08]
--DOMWINDOW == 26 (0x90c5e08) [serial = 10] [outer = 0x87bec18] [url = about:blank]
--DOCSHELL 0x935d378 == 12
--DOMWINDOW == 25 (0x93d0d00) [serial = 15] [outer = 0x935ad38] [url = about:blank]
--DOMWINDOW == 24 (0x9447cc8) [serial = 17] [outer = 0x92bfa70] [url = about:blank]
--DOMWINDOW == 23 (0x935ad68) [serial = 14] [outer = (nil)] [url = about:blank]
--DOMWINDOW == 22 (0x961c900) [serial = 26] [outer = 0x958ef08] [url = about:blank]
NEXT ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/base/content/test/browser_NetworkPrioritizer.js | Timed out
Summary: browser_NetworkPrioritizer.js randly timeouts → browser_NetworkPrioritizer.js randomly timeouts
Whiteboard: [orange]
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1256988969.1256996151.14571.gz
Linux mozilla-central test debug everythingelse on 2009/10/31 04:36:09
I was afraid this would happen. I had problems with the Linux test timing out on Try and locally, but I thought I'd managed to get them under control. I guess my fix wasn't good enough.
Assignee: nobody → paul
OS: All → Linux
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257044310.1257051354.10016.gz
Linux mozilla-central test debug everythingelse on 2009/10/31 19:58:30
Blocks: 514490
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257123495.1257132695.17913.gz#err2
Linux mozilla-central test debug everythingelse on 2009/11/01 16:58:15
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257136219.1257144587.16823.gz#err2
Linux mozilla-central test debug everythingelse on 2009/11/01 20:30:19
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257157767.1257162013.12959.gz
Linux mozilla-central test opt everythingelse on 2009/11/02 02:29:27
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257183351.1257187916.27724.gz
Linux mozilla-central test everythingelse on 2009/11/02 09:35:51
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257182661.1257187303.20828.gz
Linux mozilla-central test opt everythingelse on 2009/11/02 09:24:21
Depends on: 521233
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257187559.1257197235.6146.gz
Linux mozilla-central test debug everythingelse on 2009/11/02 10:45:59
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257179625.1257195657.20573.gz
Linux mozilla-central test debug everythingelse on 2009/11/02 08:33:45
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257199723.1257209545.14694.gz
Linux mozilla-central test debug everythingelse on 2009/11/02 14:08:43
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1257227863.1257231719.29929.gz
Linux mozilla-central test opt everythingelse on 2009/11/02 21:57:43

(a bunch of other failures followed, they don't *look* related, but mochitest is unreliable after a timeout, ya?)
As the comment in there states, waitForFocus has some issues for windows opened with a URL. So instead of wrapping with an additional waitForFocus, do it normally, but make sure that we've loaded the right URL and the focus event in waitForFocus can focus the right window.
Comment on attachment 410046 [details] [diff] [review]
Patch v0.1
[Checkin: See comment 25 & 37]

>+          // waitForFocus can attach to the wrong "window" with about:blank loading first

This sounds like the fix for bug 521233 wasn't just partly ineffective but actually wrong...
(In reply to comment #18)
> This sounds like the fix for bug 521233 wasn't just partly ineffective but
> actually wrong...

Perhaps. I think it's only wrong in this pretty specific case, where the adjusted targetWindow gets destroyed before the focus event occurs.
(In reply to comment #19)
> (In reply to comment #18)
> > This sounds like the fix for bug 521233 wasn't just partly ineffective but
> > actually wrong...
> 
> Perhaps. I think it's only wrong in this pretty specific case, where the
> adjusted targetWindow gets destroyed before the focus event occurs.

I think it's generally wrong. It waits for the content window to load, which the caller didn't ask for.
Attachment #410046 - Flags: review?(dao) → review?(enndeakin)
Comment on attachment 410046 [details] [diff] [review]
Patch v0.1
[Checkin: See comment 25 & 37]

Looks OK, although I don't know what isWindowState does.
Attachment #410046 - Flags: review?(enndeakin) → review+
(In reply to comment #23)
> (From update of attachment 410046 [details] [diff] [review])
> Looks OK, although I don't know what isWindowState does.

That's just a (poorly named) way of checking that all the tabs have the expected network priority, without having to do a specific check on each on.
I pushed http://hg.mozilla.org/mozilla-central/rev/bb2a1461026d earlier today. Test hasn't timed out yet, but I'll give it a day or so to make sure.
Haven't been any reports of this still happening, so I'm going to close it.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
This is still happening on branch - Paul, can you land this fix on 1.9.2 as well? I assume it's safe to take?

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6-Unittest/1257854150.1257856384.20928.gz
Linux mozilla-1.9.2 test everythingelse on 2009/11/10 03:55:50
This fix seems to be on 1.9.2 already.
(In reply to comment #28)
> This is still happening on branch - Paul, can you land this fix on 1.9.2 as
> well? I assume it's safe to take?
> 
> http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6-Unittest/1257854150.1257856384.20928.gz
> Linux mozilla-1.9.2 test everythingelse on 2009/11/10 03:55:50

Dão is correct, the fix is on 1.9.2 already.
(In reply to comment #30)
> (In reply to comment #28)
> > This is still happening on branch - Paul, can you land this fix on 1.9.2 as
> > well? I assume it's safe to take?
> > 
> > http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6-Unittest/1257854150.1257856384.20928.gz
> > Linux mozilla-1.9.2 test everythingelse on 2009/11/10 03:55:50
> 
> Dão is correct, the fix is on 1.9.2 already.

Well then I guess we have a problem, if it's still failing on 1.9.2 today?
The patch in bug 521233 seems to fix this.
(In reply to comment #31)
> Well then I guess we have a problem, if it's still failing on 1.9.2 today?

Indeed, especially with the frequency that it's timing out. I'm going to build 1.9.2 on Linux locally now to try some things.

(In reply to comment #32)
> The patch in bug 521233 seems to fix this.

This probably belongs on that bug, but if that patch fixes this and doesn't break anything else, then great. Were there any other tests we could convert to use waitforFocus in the cases we were concerned about (eg. chrome having with focus)?
I know you're already looking at it, but for your further edification:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6-Unittest/1257876912.1257880197.9037.gz
Linux mozilla-1.9.2 test everythingelse on 2009/11/10 10:15:12
Hmm,the output here is really weird. I knew it was timing out in a different place than before, a place where there's no good reason it should be timing out. But it's actually finishing the test and getting the right results right before the timeout for browser_bug304198.js, so I guess something in the interim tests causes focus to get shifted and waitForFocus to finish.
FYI this hasn't been happening recently because bug 514490 got backed out on branch. Hopefully I'll be relanding it today, which unfortunately means we'll be seeing a bit more of this bug again soon.
Severity: normal → blocker
Summary: browser_NetworkPrioritizer.js randomly timeouts → browser_NetworkPrioritizer.js times out constantly on 1.9.2
Version: Trunk → 3.6 Branch
No longer blocks: 438871
Whiteboard: [orange]
Attachment #410046 - Attachment description: Patch v0.1 → Patch v0.1 [Checkin: See comment 25 & 37]
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6-Unittest/1258188062.1258190686.26680.gz
Linux mozilla-1.9.2 test everythingelse on 2009/11/14 00:41:02
s: moz2-linux-slave42
Blocks: 438871
Whiteboard: [orange]
not a random orange at this point
No longer blocks: 438871
Whiteboard: [orange]
Linux mozilla-1.9.2 test everythingelse [testfailed] Started 14:56, finished 16:16

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258496970.1258502206.30821.gz
zpao: I've disabled this test for Linux due to permaorange on 1.9.2. Seems like coverage on other platforms is ok for now, nom for blocking if you think this really really has to be fixed on branch.

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5c4a8bd399e4
(In reply to comment #52)
> zpao: I've disabled this test for Linux due to permaorange on 1.9.2. Seems like
> coverage on other platforms is ok for now, nom for blocking if you think this
> really really has to be fixed on branch.
> 
> http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5c4a8bd399e4

No that's fine. I meant to do it earlier today. I don't think it's worth blocking on it since it's fine on trunk and is not reliably reproducible on branch locally.
Severity: blocker → normal
Whiteboard: [test disabled]
Might this be related to bug 531053 or bug 527784?
(In reply to comment #54)
> Might this be related to bug 531053 or bug 527784?

Since the patch in bug 521233 seemed to fix this, I don't think so.
At 2 years since this was last touched and 6 releases later, I'm WONTFIXing this. It's not disabled on trunk so we're fine.
Status: REOPENED → RESOLVED
Closed: 15 years ago13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: