Closed Bug 998608 Opened 10 years ago Closed 10 years ago

TEST-UNEXPECTED-FAIL | netwerk/test/unit/test_range_requests.js | request reports itself as not pending from onDataAvailable!

Categories

(Core :: Networking: Cache, defect)

Product:
Core
Component:
Networking: Cache
Version:
Other Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla32
Tracking Flags:
Tracking Status
firefox30 --- unaffected
firefox31 --- wontfix
firefox32 --- fixed
firefox-esr24 --- unaffected

People

(Reporter: mayhemer, Assigned: mayhemer)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

v1
2.34 KB, patch
michal
: review+
mayhemer
: checkin+
Details | Diff | Splinter Review 
05:29:43     INFO -  [4073] WARNING: unexpected progress values - is server exceeding content length?: file /builds/slave/gum-osx64-d-000000000000000000/build/netwerk/protocol/http/nsHttpChannel.cpp, line 5346

        if (progress > progressMax)
            NS_WARNING("unexpected progress values - "
                       "is server exceeding content length?");

TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/tests/xpcshell/tests/netwerk/test/unit/test_range_requests.js | test failed (with xpcshell return code: 0), see following log:
TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/tests/xpcshell/tests/netwerk/test/unit/head_channels.js | request reports itself as not pending from onDataAvailable! - See following stack:
TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/tests/xpcshell/tests/netwerk/test/unit/head_channels.js | Error in onDataAvailable: 2147500036 - See following stack:
TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/tests/xpcshell/tests/netwerk/test/unit/head_channels.js | Failed to load URL: 80004004 - See following stack:
TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/tests/xpcshell/tests/netwerk/test/unit/head_channels.js | Error in onStopRequest: 2147500036 - See following stack:
Return code: 1

https://tbpl.mozilla.org/php/getParsedLog.php?id=38142398&tree=Gum
https://hg.mozilla.org/projects/gum/rev/fcaac8e0137a
Could not reproduce locally after some 2000 iterations.
The most common way I've seen this error is from bug 748117.  Any chance we could somehow be missing a Content-Type here?  We could also just fix 748117 and see if it makes the orange go away (although occasionally omitting the Content-type would probably be a symptom of an underlying real bug).
I think this is something else.  I think we deliver partial data from the cache and then do a full request to the server (or the server doesn't respond to the range request with 206 but with 200 and a full response or with a wrong 206.)**  Maybe it's just about checking the test doesn't suffer the usual assumption that requests come to the server in the same order as made by the client.

Since this is very low rate I tend to move this to after-enable phase.



** This logic is there becuase of the concurrent read/write - when writer is interrupted (e.g. by cancelation from upper levels, e.g. docshell) request reading the entry in parallel (concurrently) needs to make a range request for the rest of the data - actually behave as the cache date were partial.
Cannot reproduce this at all.  Moving to the after-enable phase.
Blocks: cache2afterenable
No longer blocks: cache2tests
Keywords: intermittent-failure
Assignee: nobody → honzab.moz
- thanks a race condition it sometimes happens that the cache entry output stream is not closed before the second request for the same URL is made, thus the concurrent partial read logic is engaged
- we mistakenly set mIsPending flag to false before the channel makes its range request for the rest of the data
Attached patch v1 — — Splinter Review 
see comment 6
Attachment #8423840 - Flags: review?(michal.novotny)
Status: NEW → ASSIGNED
Attachment #8423840 - Flags: review?(michal.novotny) → review+
This patch had the misfortune of landing in the middle of a large bustage pileup on inbound that led to me having to revert to a last-good cset in lieu of waiting 3-4 hours for green instead. Unfortunately, that means this was backed out along with the others. If this was confirmed green on Try, it can re-land at your convenience.

https://hg.mozilla.org/integration/mozilla-inbound/rev/eb2a6f7785a2
https://hg.mozilla.org/mozilla-central/rev/b150cef6f31d
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: