Bug 19370 - [Gtk] Assertion failure at ScrollWindow.update for r34340
Summary: [Gtk] Assertion failure at ScrollWindow.update for r34340
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Critical
Assignee: Nobody
URL: http://webkit.org/blog
Keywords: Gtk
: 18444 20344 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-06-03 06:14 PDT by Jan Alonzo
Modified: 2008-10-03 22:11 PDT (History)
8 users (show)

See Also:


Attachments
Temporary workaround (1.29 KB, patch)
2008-07-17 08:28 PDT, Marco Barisione
eric: review-
Details | Formatted Diff | Diff
Reduced test case (128 bytes, text/html)
2008-08-03 05:23 PDT, Kalle Vahlman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Alonzo 2008-06-03 06:14:04 PDT
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++
Comment 1 Alp Toker 2008-06-05 19:36:10 PDT
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.
Comment 2 Marco Barisione 2008-07-17 08:28:27 PDT
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.
Comment 3 Holger Freyther 2008-07-17 10:02:11 PDT
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?
Comment 4 Xavier Claessens 2008-07-17 10:08:03 PDT
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
Comment 5 Marco Barisione 2008-07-17 10:10:59 PDT
(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.
Comment 6 Eric Seidel (no email) 2008-08-01 17:05:21 PDT
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?
Comment 7 Kalle Vahlman 2008-08-03 05:23:28 PDT
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.
Comment 8 Marco Barisione 2008-08-04 08:02:19 PDT
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)
Comment 9 Marco Barisione 2008-08-06 12:15:22 PDT
*** Bug 18444 has been marked as a duplicate of this bug. ***
Comment 10 Jan Alonzo 2008-08-10 02:02:12 PDT
#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.
Comment 11 Pierre-Luc Beaudoin 2008-08-11 07:51:28 PDT
*** Bug 20344 has been marked as a duplicate of this bug. ***
Comment 12 Jan Alonzo 2008-09-23 20:36:12 PDT
Both the reduced test case and webkit.org/blog seems to be OK now. Must've been (accidentally) fixed lately. Closing as WONTFIX.
Comment 13 Marco Barisione 2008-09-24 07:55:29 PDT
(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.
Comment 14 Jan Alonzo 2008-09-24 08:02:35 PDT
Well, it works on my curl backend build. Are you using curl or soup?
Comment 15 Jan Alonzo 2008-10-03 22:11:02 PDT
Closing as this is obsolete (due to dhyatt's refactoring of scrollviews) and test cases work fine now.