Bug 141230 - Regression(r179584): Assertion hit in toResourceLoadPriority() on Yosemite
Summary: Regression(r179584): Assertion hit in toResourceLoadPriority() on Yosemite
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords:
Depends on:
Blocks: 141186
  Show dependency treegraph
 
Reported: 2015-02-03 21:21 PST by Chris Dumez
Modified: 2015-02-03 22:25 PST (History)
2 users (show)

See Also:


Attachments
Patch (1.57 KB, patch)
2015-02-03 21:24 PST, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2015-02-03 21:21:13 PST
Regression(r179584): Assertion hit in toResourceLoadPriority() on Yosemite:
SHOULD NEVER BE REACHED
/Volumes/Data/slave/yosemite-debug/build/Source/WebCore/platform/network/cf/ResourceRequestCFNet.h(58) : WebCore::ResourceLoadPriority WebCore::toResourceLoadPriority(int)
1   0x10f2de430 WTFCrash
2   0x1149ae111 WebCore::toResourceLoadPriority(int)
3   0x1149ac9ed WebCore::ResourceRequest::doUpdateResourceRequest()
4   0x1149a97e2 WebCore::ResourceRequestBase::updateResourceRequest(WebCore::HTTPBodyUpdatePolicy) const
5   0x1149aa29e WebCore::ResourceRequestBase::url() const
6   0x11a5306de -[WebFrame loadRequest:]
7   0x10e634fa5 runTest(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)
8   0x10e633ada runTestingServerLoop()
9   0x10e63326a dumpRenderTree(int, char const**)
10  0x10e635906 DumpRenderTreeMain(int, char const**)
11  0x10e6855c2 main
12  0x7fff880015c9 start

Not sure what's happening yet. The CFNetwork doc (CFURLRequestPriority) does not indicate -1 as being a valid resource load priority value.
Comment 1 Chris Dumez 2015-02-03 21:24:52 PST
Created attachment 246014 [details]
Patch
Comment 2 Alexey Proskuryakov 2015-02-03 21:36:27 PST
> The CFNetwork doc (CFURLRequestPriority) does not indicate -1 as being a valid resource load priority value.

I recall that we define custom priority levels and don't use normal CFNetwork ones. Perhaps -1 is one of those?
Comment 3 Chris Dumez 2015-02-03 21:39:40 PST
(In reply to comment #2)
> > The CFNetwork doc (CFURLRequestPriority) does not indicate -1 as being a valid resource load priority value.
> 
> I recall that we define custom priority levels and don't use normal
> CFNetwork ones. Perhaps -1 is one of those?

Where would those be? We always call toResourceLoadPriority(wkGetHTTPRequestPriority()). I looked at the wkGetHTTPRequestPriority() implementation but couldn't find anything custom.
Comment 4 Chris Dumez 2015-02-03 21:43:26 PST
Also, when calling wkSetHTTPRequestPriority(), we always use toPlatformRequestPriority() on the priority. I took care in r179584 to remove -1 from that function already so we should never be setting -1 ourselves.
Comment 5 Alexey Proskuryakov 2015-02-03 21:49:22 PST
Looking at CFURLRequest.h, CFURLRequestPriority is documented to have values from 0 to 2. However, we call WKSetHTTPRequestMaximumPriority to change that, and use values up to 4.

This indeed doesn't answer the question of where -1 comes from. Did you check CFNetwork source code?
Comment 6 Chris Dumez 2015-02-03 21:51:27 PST
(In reply to comment #5)
> Looking at CFURLRequest.h, CFURLRequestPriority is documented to have values
> from 0 to 2. However, we call WKSetHTTPRequestMaximumPriority to change
> that, and use values up to 4.
> 
> This indeed doesn't answer the question of where -1 comes from. Did you
> check CFNetwork source code?

Yes, this is what I am currently doing (so far no explanation though). I still think we should land this patch in the mean time though to make the bots happy. We were handling -1 in this function prior to r179584 already.
Comment 7 Chris Dumez 2015-02-03 22:25:06 PST
Comment on attachment 246014 [details]
Patch

Clearing flags on attachment: 246014

Committed r179593: <http://trac.webkit.org/changeset/179593>
Comment 8 Chris Dumez 2015-02-03 22:25:12 PST
All reviewed patches have been landed.  Closing bug.