25659 2009-05-08 21:08:02 -0700 Calling frameCount() from BitmapImage::destroyDecodedDataIfNecessary() can cause GIF decoding 2009-05-28 10:29:31 -0700 1 1 1 Unclassified WebKit Images 528+ (Nightly build) Mac OS X 10.5 RESOLVED FIXED P2 Normal --- 1 simon.fraser pkasting pkasting oldest_to_newest 120502 0 simon.fraser 2009-05-08 21:08:02 -0700 I noticed a stack where, during destruction of an HTMLImageElement, we can actually do some GIF decoding because we're trying to get frameCount(): 15 WebCore 112.00 Kb WebCore::Document::removedLastRef() /Volumes/WebKit/WebKit.git/WebCore/dom/Document.cpp:413 14 WebCore 112.00 Kb WebCore::ContainerNode::removeAllChildren() /Volumes/WebKit/WebKit.git/WebCore/dom/ContainerNode.cpp:56 13 WebCore 112.00 Kb void WebCore::removeAllChildrenInContainer<WebCore::Node, WebCore::ContainerNode>(WebCore::ContainerNode*) /Volumes/WebKit/WebKit.git/WebCore/dom/ContainerNodeAlgorithms.h:51 12 WebCore 112.00 Kb WebCore::HTMLImageElement::~HTMLImageElement() 11 WebCore 112.00 Kb WebCore::HTMLImageLoader::~HTMLImageLoader() 10 WebCore 112.00 Kb WebCore::ImageLoader::~ImageLoader() 9 WebCore 112.00 Kb WebCore::CachedResource::removeClient(WebCore::CachedResourceClient*) /Volumes/WebKit/WebKit.git/WebCore/loader/CachedResource.cpp:166 8 WebCore 112.00 Kb WebCore::CachedImage::allClientsRemoved() /Volumes/WebKit/WebKit.git/WebCore/loader/CachedImage.cpp:112 7 WebCore 112.00 Kb WebCore::BitmapImage::resetAnimation() /Volumes/WebKit/WebKit.git/WebCore/platform/graphics/BitmapImage.cpp:378 6 WebCore 112.00 Kb WebCore::BitmapImage::destroyDecodedDataIfNecessary(bool) /Volumes/WebKit/WebKit.git/WebCore/platform/graphics/BitmapImage.cpp:98 5 WebCore 112.00 Kb WebCore::BitmapImage::frameCount() /Volumes/WebKit/WebKit.git/WebCore/platform/graphics/BitmapImage.cpp:187 4 WebCore 112.00 Kb WebCore::ImageSource::frameCount() const /Volumes/WebKit/WebKit.git/WebCore/platform/graphics/cg/ImageSourceCG.cpp:174 3 ImageIO 112.00 Kb CGImageSourceGetCount 2 ImageIO 112.00 Kb gifPluginImageCount 1 libGIF.dylib 112.00 Kb _cg_DGifOpen 0 libSystem.B.dylib 112.00 Kb malloc 123343 1 pkasting 2009-05-27 17:25:23 -0700 I think destroyDecodedData() should be checking m_frames.size() instead of frameCount(). m_frames.size() represents how many frames we have potentially decoded (though some or all may currently be empty), while frameCount() is the size of the whole image. We never really care how big the image theoretically is, just how much data we could actually have lying around at the moment. 123352 2 30726 pkasting 2009-05-27 18:19:18 -0700 Created attachment 30726 patch v1 This should fix it. 123433 3 pkasting 2009-05-28 10:29:31 -0700 Fixed in r44237. 30726 2009-05-27 18:19:18 -0700 2009-05-27 20:45:11 -0700 patch v1 patch text/plain 1293 pkasting SW5kZXg6IFdlYkNvcmUvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFdlYkNvcmUvQ2hhbmdlTG9n CShyZXZpc2lvbiA0NDIxMikKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBA IC0xLDMgKzEsMTQgQEAKKzIwMDktMDUtMjcgIFBldGVyIEthc3RpbmcgIDxwa2FzdGluZ0Bnb29n bGUuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg IGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yNTY1OQorICAgICAgICBB dm9pZCBjYWxsaW5nIGZyYW1lQ291bnQoKSB1bm5lY2Vzc2FyaWx5ICh3aGljaCBjb3VsZCBsZWFk IHRvIGV4dHJhCisgICAgICAgIEdJRiBkZWNvZGluZykuCisKKyAgICAgICAgKiBwbGF0Zm9ybS9n cmFwaGljcy9CaXRtYXBJbWFnZS5jcHA6CisgICAgICAgIChXZWJDb3JlOjpCaXRtYXBJbWFnZTo6 ZGVzdHJveURlY29kZWREYXRhSWZOZWNlc3NhcnkpOgorCiAyMDA5LTA1LTI3ICBEaW1pdHJpIEds YXprb3YgIDxkZ2xhemtvdkBjaHJvbWl1bS5vcmc+CiAKICAgICAgICAgVW5yZXZpZXdlZCwgYnVp bGQgZml4LgpJbmRleDogV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9CaXRtYXBJbWFnZS5jcHAK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9CaXRtYXBJbWFnZS5jcHAJ KHJldmlzaW9uIDQ0MjEyKQorKysgV2ViQ29yZS9wbGF0Zm9ybS9ncmFwaGljcy9CaXRtYXBJbWFn ZS5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTk1LDcgKzk1LDcgQEAgdm9pZCBCaXRtYXBJbWFnZTo6 ZGVzdHJveURlY29kZWREYXRhSWZOZQogICAgIC8vIEFuaW1hdGVkIGltYWdlcyA+NU1CIGFyZSBj b25zaWRlcmVkIGxhcmdlIGVub3VnaCB0aGF0IHdlJ2xsIG9ubHkgaGFuZyBvbgogICAgIC8vIHRv IG9uZSBmcmFtZSBhdCBhIHRpbWUuCiAgICAgc3RhdGljIGNvbnN0IHVuc2lnbmVkIGNMYXJnZUFu aW1hdGlvbkN1dG9mZiA9IDUyNDI4ODA7Ci0gICAgaWYgKGZyYW1lQ291bnQoKSAqIGZyYW1lQnl0 ZXMobV9zaXplKSA+IGNMYXJnZUFuaW1hdGlvbkN1dG9mZikKKyAgICBpZiAobV9mcmFtZXMuc2l6 ZSgpICogZnJhbWVCeXRlcyhtX3NpemUpID4gY0xhcmdlQW5pbWF0aW9uQ3V0b2ZmKQogICAgICAg ICBkZXN0cm95RGVjb2RlZERhdGEoZGVzdHJveUFsbCk7CiB9CiAK