Bug 92774 – Crash in FrameLoader::checkLoadComplete with non-browser client app

• Status: RESOLVED
• Resolution: FIXED
• Component: Page Loading

[Antti Koivisto]

Seen with a non-browser client app

0   WebCore                       	0x327aaf3c WebCore::FrameLoader::checkLoadComplete() (FrameLoader.cpp:2399)
1   WebCore                       	0x32a6cd30 WebCore::CSSFontSelector::beginLoadTimerFired(WebCore::Timer<WebCore::CSSFontSelector>*) (CSSFontSelector.cpp:619)
2   WebCore                       	0x327e69a6 WebCore::ThreadTimers::sharedTimerFiredInternal() (ThreadTimers.cpp:129)

[Antti Koivisto]

<rdar://problem/11956222>

[Antti Koivisto]

Created attachment 155591 [details]
speculative fix

[Alexey Proskuryakov]

Comment on attachment 155591 [details]
speculative fix

View in context: https://bugs.webkit.org/attachment.cgi?id=155591&action=review

> Source/WebCore/css/CSSFontSelector.cpp:581
> +    // It is possible load calls could cause CSSFontSelector to get deleted synchronously.

"CSSFontSelector can be deleted via beginLoadIfNeeded() or loadDone() unless protected." (or better something more specific about how that could happen).

Both "possible" and "could" make this difficult to read.

> Source/WebCore/css/CSSFontSelector.cpp:582
> +    // If detached clearDocument() will get called ensuring m_document is null.

I think that you're explaining why m_document won't be a dangling pointer, but that seems excessive. We don't make such comment every time we use a member variable pointing to some other object, and don't make it for every variable that has a clearXXX() method. Is there something unusual here that needs to be explained?

[Antti Koivisto]

http://trac.webkit.org/changeset/124229

[Abhishek Arya]

*** Bug 91701 has been marked as a duplicate of this bug. ***

[Abhishek Arya]

Confirming at the testcase we had at ClusterFuzz got fixed by your AWESOMENESS :)

[Alexey Proskuryakov]

Great! Can we have the test case landed then?