Bug 19370 – [Gtk] Assertion failure at ScrollWindow.update for r34340

• Component: WebKitGTK
• Status: RESOLVED WONTFIX

[Jan Alonzo]

Here's a backtrace:

[New process 6778]
#0  0x00007fa9169c27c3 in WebCore::ScrollView::update (this=<value optimized out>) at WebCore/platform/gtk/ScrollViewGtk.cpp:321
321         ASSERT(containingWindow());
(gdb) bt
#0  0x00007fa9169c27c3 in WebCore::ScrollView::update (this=<value optimized out>) at WebCore/platform/gtk/ScrollViewGtk.cpp:321
#1  0x00007fa9161d1e76 in WebCore::Document::implicitClose (this=0x23e48e0) at WebCore/dom/Document.cpp:1590
#2  0x00007fa91647d7b8 in WebCore::FrameLoader::checkCompleted (this=0x23d5598) at WebCore/loader/FrameLoader.cpp:1291
#3  0x00007fa91647f842 in WebCore::FrameLoader::finishedParsing (this=0x23d5598) at WebCore/loader/FrameLoader.cpp:1241
#4  0x00007fa9161c1bdd in WebCore::Document::finishedParsing (this=0x23e48e0) at WebCore/dom/Document.cpp:3730
#5  0x00007fa91647b0cc in WebCore::FrameLoader::endIfNotLoadingMainResource (this=0x23d5598) at WebCore/loader/FrameLoader.cpp:1070
#6  0x00007fa91696a0f7 in WebCore::SVGImage::dataChanged (this=0x237cae0, allDataReceived=<value optimized out>) at WebCore/svg/graphics/SVGImage.cpp:222
#7  0x00007fa916594182 in WebCore::Image::setData (this=0x237cae0, data=<value optimized out>, allDataReceived=false) at WebCore/platform/graphics/Image.cpp:72
#8  0x00007fa91644678d in WebCore::CachedImage::data (this=0x21833c0, data=<value optimized out>, allDataReceived=192) at WebCore/loader/CachedImage.cpp:233
#9  0x00007fa91649c7f5 in WebCore::Loader::Host::didFinishLoading (this=0x2054970, loader=0x237fa50) at WebCore/loader/loader.cpp:268
#10 0x00007fa9164b1b66 in WebCore::SubresourceLoader::didFinishLoading (this=0x237fa50) at WebCore/loader/SubresourceLoader.cpp:193
#11 0x00007fa91671f32b in WebCore::ResourceHandleManager::downloadTimerCallback (this=0x1de33a0, timer=<value optimized out>) at WebCore/platform/network/curl/ResourceHandleManager.cpp:298
#12 0x00007fa9165d1000 in WebCore::TimerBase::fireTimers (fireTime=1212497292.2715991, firingTimers=@0x7fff1f89a6a0) at WebCore/platform/Timer.cpp:347
#13 0x00007fa9165d1110 in WebCore::TimerBase::sharedTimerFired () at WebCore/platform/Timer.cpp:368
#14 0x00007fa9169c72b2 in timeout_cb () at WebCore/platform/gtk/SharedTimerGtk.cpp:48
#15 0x00007fa914bde81b in ?? () from /usr/lib/libglib-2.0.so.0
#16 0x00007fa914bde0f2 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#17 0x00007fa914be1396 in ?? () from /usr/lib/libglib-2.0.so.0
#18 0x00007fa914be1657 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#19 0x00007fa9151ecc43 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#20 0x0000000000401ecb in main (argc=1, argv=0x7fff1f89a9f8) at WebKitTools/GtkLauncher/main.c:200
Current language:  auto; currently c++

[Alp Toker]

Thanks for the trace. It'd be best to figure out why this is null, but it might be worth adding a nullcheck to avoid crashes for users in the meantime if debugging doesn't get us anywhere.

[Marco Barisione]

Created attachment 22339 [details]
Temporary workaround

Usually I don't like this kind of workarounds but I wasn't able to find the real reason for this problem and this bug is very annoying.

[Holger Freyther]

Okay. Is that the FrameView of the main frame? Looks like we have detached the containing window from the WebCore::FrameView but then do something with the FrameView... So the above URL is enough to make that happen? Does this happen with page cache turned off?

[Xavier Claessens]

I can reproduce this bug with empathy, using webkit to render adium themes. It happens when a contact don't have an avatar so it get replaced by a SVG icon.

To reproduce:

1) Take the adium empathy branch:
http://git.collabora.co.uk/?p=user/xclaesse/empathy.git;a=shortlog;h=refs/heads/adium
2) Put the "Contents" dir of an adium theme in you home
3) In the preference dialog select 'adium'
4) start a chat with someone that have no avatar

[Marco Barisione]

(In reply to comment #3)
> Okay. Is that the FrameView of the main frame?

Frame view.

> Looks like we have detached the
> containing window from the WebCore::FrameView but then do something with the
> FrameView...

Yes, but I cannot find where the problem is and why it happens.

> So the above URL is enough to make that happen? Does this happen
> with page cache turned off?

Yes, that's enough. I can reproduce the bug also in other ways, for instace using the experimental code for adium thems in the empathy IM client.

[Eric Seidel (no email)]

Comment on attachment 22339 [details]
Temporary workaround

Better to fix the bug, or explain why it is OK for a ScrollView to ever not have a window.  Printing perhaps?  During teardown?

[Kalle Vahlman]

Created attachment 22622 [details]
Reduced test case

Here's a reduced test case.

Seems that the problem is with showing any SVG in an img tag.

[Marco Barisione]

It seems that the bug is only visible when you have a SVG inside an <img> tag. This is supported only by WebKit and this is why we were seeing the crash only on pages thought to be viewed in WebKit.

The reason for the crash is that SVGImage contains a FrameView and FrameView derives from ScrollView. The FrameView doesn't have an associated widget -> crash.

Why are svg images in <img> treated in a different way? If that's normal is it normal that they don't have an associated widget? (I think so but I don't know that code)

[Marco Barisione]

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

[Jan Alonzo]

#8  0x00007f3c1f01f610 in WebCore::Loader::Host::didFinishLoading (this=0xa8ff40, loader=0xceb0d0) at ../../WebCore/loader/loader.cpp:275
#9  0x00007f3c1f033331 in WebCore::SubresourceLoader::didFinishLoading (this=0xceb0d0) at ../../WebCore/loader/SubresourceLoader.cpp:196

I started looking at those parts of the stack in Host::didFinishLoading, [CachedResource*] resource->size() is 0 here. Whereas for non-svg images this is the size of the image. There's probably something wrong with the way we're loading SVG images.

[Pierre-Luc Beaudoin]

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

[Jan Alonzo]

Both the reduced test case and webkit.org/blog seems to be OK now. Must've been (accidentally) fixed lately. Closing as WONTFIX.

[Marco Barisione]

(In reply to comment #12)
> Both the reduced test case and webkit.org/blog seems to be OK now. Must've been
> (accidentally) fixed lately. Closing as WONTFIX.

Are you sure? I can still reproduce it with an updated copy of webkit.

[Jan Alonzo]

Well, it works on my curl backend build. Are you using curl or soup?

[Jan Alonzo]

Closing as this is obsolete (due to dhyatt's refactoring of scrollviews) and test cases work fine now.