During loading some resources, especially when loading was failed segfault occurred because activeDocumentLoader() has been already destroyed. See callstack in an attachment. It happens when encoding for the request is set and activeDocumentLoader() checks frame's encoding. You can check this on www.latimes.com when WebKit gets resource: https://latimes.signon.trb.com/registration/xd/xd_sender.htm
Created attachment 90685 [details] Callstack
Created attachment 90687 [details] patch
This would need a regression test to be landed. However, I doubt that this is the right fix. This problem is not known to occur in other ports, so you should look into what destroys activeDocumentLoader too early, and fix that.
(In reply to comment #3) > This would need a regression test to be landed. > > However, I doubt that this is the right fix. This problem is not known to occur in other ports, so you should look into what destroys activeDocumentLoader too early, and fix that. Ok, the reason of this issue was found. Anyway methods: - FrameLoader::isLoading() - FrameLoader::checkLoadCompleteForThisFrame() checks returned value of activeDocumentLoader() but some of them in FrameLoader not. Do you think that it's safe to have an access to the object if it may return NULL?
Adding checks when we know that the returned value can't be null would be very confusing to readers. By having a null check, we're saying that the situation is expected, and we need to handle it adequately. The document encoding is an important part of fallback, so skipping it is not adequate. We would need to find another way to retrieve the document encoding if activeDocumentLoader could be null here.
Ok, thanks for your explanation. I think we can close this bug as invalid.