RESOLVED WONTFIX19370
[Gtk] Assertion failure at ScrollWindow.update for r34340 
https://bugs.webkit.org/show_bug.cgi?id=19370
Summary [Gtk] Assertion failure at ScrollWindow.update for r34340
Jan Alonzo
Reported 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++
Attachments
Temporary workaround (1.29 KB, patch)
2008-07-17 08:28 PDT, Marco Barisione 		eric: review-
DetailsFormatted DiffDiff
Reduced test case (128 bytes, text/html)
2008-08-03 05:23 PDT, Kalle Vahlman 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Alp Toker
Comment 1 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.
Marco Barisione
Comment 2 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.
Holger Freyther
Comment 3 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?
Xavier Claessens
Comment 4 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
Marco Barisione
Comment 5 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.
Eric Seidel (no email)
Comment 6 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?
Kalle Vahlman
Comment 7 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.
Marco Barisione
Comment 8 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)
Marco Barisione
Comment 9 2008-08-06 12:15:22 PDT
*** Bug 18444 has been marked as a duplicate of this bug. ***
Jan Alonzo
Comment 10 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.
Pierre-Luc Beaudoin
Comment 11 2008-08-11 07:51:28 PDT
*** Bug 20344 has been marked as a duplicate of this bug. ***
Jan Alonzo
Comment 12 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.
Marco Barisione
Comment 13 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.
Jan Alonzo
Comment 14 2008-09-24 08:02:35 PDT
Well, it works on my curl backend build. Are you using curl or soup?
Jan Alonzo
Comment 15 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.
Note You need to log in before you can comment on or make changes to this bug.