Closed Bug 656943 Opened 14 years ago Closed 3 years ago

test_offlineMode.html | Able to fetch unlisted resource, not properly associated

Categories

(Core :: Networking: Cache, defect, P3)

Product:
Core
Component:
Networking: Cache
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: mfinkle, Unassigned)

References

Details

(Keywords: intermittent-failure, Whiteboard: [test disabled][please leave open][necko-backlog])

Attachments

(1 file)

disable it
1.06 KB, patch
hsivonen
: review+
Details | Diff | Splinter Review
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1305300253.1305303264.3413.gz s: talos-r3-leopard-022 5673 ERROR TEST-UNEXPECTED-FAIL | /tests/dom/tests/mochitest/ajax/offline/test_offlineMode.html | Able to fetch unlisted resource, not properly associated. Filing a bug because the push this happened was a Mobile-only logo and text branding patch.
Blocks: 438871
Henri, this orange occurred for the first time shortly after bug 651441 landed. Is it possible that it's somehow related?
(In reply to comment #3) > Henri, this orange occurred for the first time shortly after bug 651441 > landed. Is it possible that it's somehow related? It is *possible* that they are related, since bug 651441 affected the processing of http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/ajax/offline/notonwhitelist.html?force=1 and http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/ajax/offline/updatingIframe.sjs I'd blame this on a flaky test, though, since bug 651441 has had several clean try and main tinderbox runs.
(In reply to comment #4) > (In reply to comment #3) > > Henri, this orange occurred for the first time shortly after bug 651441 > > landed. Is it possible that it's somehow related? > > It is *possible* that they are related, since bug 651441 affected the > processing of > http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/ajax/ > offline/notonwhitelist.html?force=1 > and > http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/ajax/ > offline/updatingIframe.sjs In that case, I'd suspect that bug 651441 is the real culprit, because the unexpected cache hit is for notonwhitelist.html. > I'd blame this on a flaky test, though, since bug 651441 has had several > clean try and main tinderbox runs. Well, this bug is not frequent enough to happen on every test run, so I wouldn't read too much into those clean try runs. Do you object to backing bug 651441 out and seeing if it actually makes this orange stop, so that we can know how to deal with it with some certainty?
Also, as an interesting pattern to this failure, there is a warning right before the failure in the debug run logs which doesn't seem to occur on green mochitest-2 runs: WARNING: NS_ENSURE_TRUE(!mCacheUpdate) failed: file e:/builds/moz2_slave/cen-w32-dbg/build/dom/src/offline/nsDOMOfflineResourceList.cpp, line 836
(In reply to comment #47) > (In reply to comment #4) > > (In reply to comment #3) > > > Henri, this orange occurred for the first time shortly after bug 651441 > > > landed. Is it possible that it's somehow related? > > > > It is *possible* that they are related, since bug 651441 affected the > > processing of > > http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/ajax/ > > offline/notonwhitelist.html?force=1 > > and > > http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/ajax/ > > offline/updatingIframe.sjs > > In that case, I'd suspect that bug 651441 is the real culprit, because the > unexpected cache hit is for notonwhitelist.html. I expect it to be "the real culprit" only to the extent of being the last straw that exposed a bug that already existed in the tree. That is, it seems completely implausible that the change from bug 651441 itself could be a source of randomness. Note that fix for bug 651441 makes the randomly-failing test run code that the test case was already running in Firefox 3.6. > > I'd blame this on a flaky test, though, since bug 651441 has had several > > clean try and main tinderbox runs. > > Well, this bug is not frequent enough to happen on every test run, so I > wouldn't read too much into those clean try runs. > > Do you object to backing bug 651441 out and seeing if it actually makes this > orange stop, so that we can know how to deal with it with some certainty? I object to backing it out on beta or aurora. I'm ok with backing it out on central and relanding soonish in order to confirm that the randomness has to have something to do with the two URLs mentioned in comment 4. I'd be unhappy about keeping bug 651441 backed out until the real cause of randomness is found, though, because it would be bad to let Firefox 7 re-regress what the patch fixed. (In reply to comment #48) > Also, as an interesting pattern to this failure, there is a warning right > before the failure in the debug run logs which doesn't seem to occur on > green mochitest-2 runs: > > WARNING: NS_ENSURE_TRUE(!mCacheUpdate) failed: file > e:/builds/moz2_slave/cen-w32-dbg/build/dom/src/offline/ > nsDOMOfflineResourceList.cpp, line 836 Honza, does this suggest to you what is happening here?
(In reply to comment #49) > (In reply to comment #48) > > Also, as an interesting pattern to this failure, there is a warning right > > before the failure in the debug run logs which doesn't seem to occur on > > green mochitest-2 runs: > > > > WARNING: NS_ENSURE_TRUE(!mCacheUpdate) failed: file > > e:/builds/moz2_slave/cen-w32-dbg/build/dom/src/offline/ > > nsDOMOfflineResourceList.cpp, line 836 > > Honza, does this suggest to you what is happening here? I guess I'll wait a bit to see if Honza has any ideas.
Ehsan, Henri, thanks for the catch with NS_ENSURE_TRUE. It means there is an update in progress, probably invoked by an early launched test, that may interfere with the failing. I have to try to reproduce and have a log. I agree with Henri NOT TO back bug 651441 out. It just makes a different bug happen more often.
Attached patch disable it — — Splinter Review
It seems a bit odd to "blame this on a flaky test" given that it failed zero times in two and a half years, and has now failed 540-odd times in half a year, but maybe it, um, took time to start flaking or something. Go ahead, the gun's against its head, pull the trigger.
Attachment #578890 - Flags: review?(hsivonen)
OS: Linux → All
Hardware: x86 → All
Version: unspecified → Trunk
anything I need to do I dont know much about computers.
Attachment #578890 - Flags: review?(hsivonen) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/61b93d0a8624
Whiteboard: [orange] → [orange][test disabled][please leave open]
(In reply to Phil Ringnalda (:philor) from comment #554) > https://hg.mozilla.org/integration/mozilla-inbound/rev/61b93d0a8624 Ah, I know it takes a lot of time for me take a look at this, but I will soon probably need to re-enable the test and add some debugging log since I have no idea at the moment what the cause could be.
Well, we know from the last 540 failures that it's particularly common on 10.6 opt and Win PGO - when the time comes, if you don't remember how to get PGO out of the tryserver, ping me and I'll remind you, and then you can enable it there and retrigger mochitests until you get your logging info.
Test disabled on mozilla-central for 11.0: https://hg.mozilla.org/mozilla-central/rev/61b93d0a8624
This test is the most important from all offline tests we have. I'll take a look at this.
Assignee: nobody → honzab.moz
Whiteboard: [orange][test disabled][please leave open] → [test disabled][please leave open]
This could have been fixed with changes in bug 892488, retrying: https://tbpl.mozilla.org/?tree=Try&rev=046c2dfa3b4d
Another attempt: https://tbpl.mozilla.org/?tree=Try&rev=89af60d50907 Still, problem here is that these days we cannot cut off access to the server since it's running on local host (io service will allow connect to it) :( so the test is useless... Patrick, is there a pref to cut even localhost connections with IOService.offline = true?
Flags: needinfo?(mcmanus)
localhost is allowed when in offline mode.. we could add another pref if it would help..
Flags: needinfo?(mcmanus)
Assignee: honzab.moz → nobody
Whiteboard: [test disabled][please leave open] → [test disabled][please leave open][necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3

Bulk closing some old intermittents.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: