Bug 155109 – Crash in WebCore::RenderElement::containingBlockForObjectInFlow

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Michael Catanzaro]

Created attachment 273175 [details]
Backtrace

I can't reproduce this, but a user testing WebKitGTK+ 2.11.91 reports that WebKit crashes whenever he visits www.seznam.cz in WebCore::RenderElement::containingBlockForObjectInFlow. Backtrace attached.

[alan]

Created attachment 273221 [details]
Patch

[alan]

I wasn't able to rerpo this, but it's certainly unsafe to call containingBlock() unconditionally in that loop.

[Simon Fraser (smfr)]

Comment on attachment 273221 [details]
Patch

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

> Source/WebCore/rendering/RenderBlock.cpp:259
> +            while (containingBlock && (containingBlock->style().position() == StaticPosition || (containingBlock->isInline() && !containingBlock->isReplaced()))
> +                && !is<RenderView>(*containingBlock)) {

I would put the RenderView check at the beginning:

while (containingBlock && !is<RenderView>(*containingBlock)...

> Source/WebCore/rendering/RenderBoxModelObject.cpp:243
> +    while (cb && cb->isAnonymous() && !is<RenderView>(*cb))

!is<RenderView>(*cb) second.

> Source/WebCore/rendering/RenderFlowThread.cpp:446
> +        while (objContainingBlock && !objContainingBlock->isRenderNamedFlowThread() && !is<RenderView>(*objContainingBlock)) {

while (objContainingBlock && !is<RenderView>(*objContainingBlock)

> Source/WebCore/rendering/RenderFlowThread.cpp:1228
> +    while (currentBlock && !currentBlock->isRenderFlowThread() && !is<RenderView>(*currentBlock)) {

Same

[alan]

Created attachment 273224 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 273224 [details]
Patch

Clearing flags on attachment: 273224

Committed r197716: <http://trac.webkit.org/changeset/197716>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Michael Catanzaro]

Created attachment 274905 [details]
Backtrace with WebKitGTK+ 2.12.0

Unfortunately this patch didn't fix it; I have so far eight reports of this crash with WebKitGTK+ 2.11.92 (which includes the patch in this bug) and 12 with 2.12.0. Here's a backtrace taken with 2.12.0.

FWIW, it seems likely that the crash was introduced in 2.11.90 as I couldn't find any prior reports of this, so it's probably due to some recent change.

[Michael Catanzaro]

Oh and a reported reproducer:

"I've tried to add an online account, selecting Facebook as provider.
If I switch to caps lock while typing the password, the dialog crashes.

Of course, this happens to other web services, like Google and Microsoft."

I couldn't reproduce this issue in my jhbuild environment. The web view in this case is displaying https://www.facebook.com/login

[alan]

(In reply to comment #7)
> Created attachment 274905 [details]
> Backtrace with WebKitGTK+ 2.12.0
> 
> Unfortunately this patch didn't fix it; I have so far eight reports of this
> crash with WebKitGTK+ 2.11.92 (which includes the patch in this bug) and 12
> with 2.12.0. Here's a backtrace taken with 2.12.0.
> 
> FWIW, it seems likely that the crash was introduced in 2.11.90 as I couldn't
> find any prior reports of this, so it's probably due to some recent change.

The attached backtrace shows a different issue. I'll file a new bugzilla for it.

[Michael Catanzaro]

OK, thanks.

[Radar WebKit Bug Importer]

<rdar://problem/25362489>