| Summary: | Crash in WebCore::ResourceError::cfError() after provisional load failed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | David Kilzer (:ddkilzer) <ddkilzer> | ||||
| Component: | Page Loading | Assignee: | David Kilzer (:ddkilzer) <ddkilzer> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | aestes, beidson, commit-queue, darin, koivisto | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 146391 | ||||||
| Attachments: |
|
||||||
|
Description
David Kilzer (:ddkilzer)
2015-06-27 07:32:17 PDT
Created attachment 255699 [details]
Patch v1
Comment on attachment 255699 [details]
Patch v1
Not sure the logging is needed.
Comment on attachment 255699 [details] Patch v1 Clearing flags on attachment: 255699 Committed r186035: <http://trac.webkit.org/changeset/186035> All reviewed patches have been landed. Closing bug. (In reply to comment #3) > Comment on attachment 255699 [details] > Patch v1 > > Not sure the logging is needed. This code hadn't changed recently, so the reason why the URL is invalid (can't be parsed) seems interesting enough to warrant a log. Or would you have preferred an ASSERT() with a NULL check instead? (In reply to comment #6) > (In reply to comment #3) > > Comment on attachment 255699 [details] > > Patch v1 > > > > Not sure the logging is needed. > > This code hadn't changed recently, so the reason why the URL is invalid > (can't be parsed) seems interesting enough to warrant a log. > > Or would you have preferred an ASSERT() with a NULL check instead? Oh, Darin removed the LOG statement in a build fix: Committed r186036: <http://trac.webkit.org/changeset/186036> I agree that the reason why the URL can’t be parsed could be interesting, but please keep in mind that adding this log statement is unlikely to actually help us find these cases and also such a failure is unsurprising. The function we are using the convert the URL string to a URL is pretty picky and is something we long ago discovered we couldn’t generally use for URLs found on the web. We could add the logging back, but I am not sure who exactly would be using this to probe the mystery and when. Better, I think, to fix the known problem by using the better functions for making URLs that we use for other purposes, as I allude to in the FIXME, which I think is what bug 146391 is about. |