Bug 16200 - [GTK] Crashes caused by animated GIFs
Summary: [GTK] Crashes caused by animated GIFs
Status: RESOLVED DUPLICATE of bug 111179
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://pvanhoof.be/files/TMutFetchAsN...
Keywords: Cairo, Gtk
: 16728 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-30 02:01 PST by Alp Toker
Modified: 2017-03-06 10:34 PST (History)
14 users (show)

See Also:


Attachments
Core dump. GtkLauncher, r152392, 64-bit DEBUG build (7.29 MB, application/octet-stream)
2013-07-05 02:26 PDT, Simon Pena
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alp Toker 2007-11-30 02:01:06 PST
Animated GIFs often crash GtkLauncher, particularly large ones. There is often also image corruption evident when the GIFs are rendered on screen.

The issue is probably not in the image decoders since they work fine for Android and the experimental Qt branch. Could be a problem in WebCore/platform/graphics/cairo
Comment 1 Alp Toker 2007-12-03 05:53:31 PST
Commit r28345 fixed the image corruption issues by removing a misplaced 'delete'.

The crashes are still unresolved.
Comment 2 Alp Toker 2008-01-07 07:02:10 PST
*** Bug 16728 has been marked as a duplicate of this bug. ***
Comment 3 Jan Alonzo 2008-04-20 14:23:20 PDT
The GIF doesn't make it crash anymore but there's still an issue with corruption in rendering while the gif is still being loaded by webkit.
Comment 4 zaheer 2008-05-15 02:48:59 PDT
the animated gif at http://content.ytmnd.com/content/6/a/0/6a0e42120c9f9e24dfc3bfa353ccd114.gif crashes on my arm build (based on r31307) with the following backtrace

#0  fbFetchPixel_a8r8g8b8 (bits=0x42878008, offset=0, indexed=0x0) at fbcompose.c:669
#1  0x405085c4 in fbFetchTransformed (pict=0x178cd0, x=0, y=0, width=240, buffer=0xbed028ac, mask=0x0, 
    maskBits=4278190080) at fbcompose.c:3448
#2  0x405099bc in pixman_compositeGeneral (op=3201313900, pSrc=0x178cd0, pMask=0x0, pDst=0x405020bc, 
    xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=0, yDst=0, width=0, height=125) at fbcompose.c:4196
#3  0x404f7eb0 in _cairo_pixman_composite (op=PIXMAN_OPERATOR_SRC, pSrc=0x178cd0, pMask=0x0, 
    pDst=0x181a90, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=0, yDst=0, width=240, height=125)
    at fbpict.c:1928
#4  0x404bf118 in _cairo_image_surface_composite (op=CAIRO_OPERATOR_SOURCE, src_pattern=0xbed08dc4, 
    mask_pattern=0x0, abstract_dst=0x1824c0, src_x=0, src_y=0, mask_x=0, mask_y=0, dst_x=0, dst_y=0, 
    width=240, height=125) at cairo-image-surface.c:857
#5  0x404c982c in _cairo_surface_composite (op=CAIRO_OPERATOR_SOURCE, src=0xbed08dc4, mask=0x0, 
    dst=0x1824c0, src_x=0, src_y=0, mask_x=0, mask_y=0, dst_x=0, dst_y=0, width=240, height=125)
    at cairo-surface.c:1155
#6  0x404cc564 in _cairo_surface_fallback_composite (op=CAIRO_OPERATOR_CLEAR, src=0xbed08dc4, mask=0x0, 
    dst=0x40500748, src_x=1, src_y=1078773092, mask_x=1, mask_y=1078773092, dst_x=0, dst_y=0, width=240, 
    height=125) at cairo-surface-fallback.c:1110
#7  0x404cb86c in _clip_and_composite_trapezoids (src=0xbed08dc4, op=CAIRO_OPERATOR_SOURCE, dst=0x178a10, 
    traps=0xbed08d30, clip=0x1823ac, antialias=CAIRO_ANTIALIAS_NONE) at cairo-surface-fallback.c:448
#8  0x404cc094 in _cairo_surface_fallback_fill (surface=0x178a10, op=CAIRO_OPERATOR_SOURCE, 
    source=0xbed08dc4, path=0x178730, fill_rule=CAIRO_FILL_RULE_WINDING, tolerance=0.10000000000000001, 
    antialias=CAIRO_ANTIALIAS_NONE) at cairo-surface-fallback.c:907
#9  0x404caa98 in _cairo_surface_fill (surface=0x9999999a, op=CAIRO_OPERATOR_SOURCE, source=0x42878008, 
    path=0x178730, fill_rule=CAIRO_FILL_RULE_WINDING, tolerance=0.10000000000000001, 
    antialias=CAIRO_ANTIALIAS_DEFAULT) at cairo-surface.c:1454
#10 0x404bcd24 in _cairo_gstate_fill (gstate=0x3fb99999, path=0x9999999a) at cairo-gstate.c:1044
#11 0x404b651c in *INT_cairo_fill_preserve (cr=0x1785c0) at cairo.c:2096
#12 0x404b6544 in cairo_fill (cr=0x1785c0) at cairo.c:2072
#13 0x40a00a0c in WebCore::BitmapImage::draw () from /usr/local/lib/libwebkit-1.0.so.1
#14 0x40cdb9ac in WebCore::GraphicsContext::drawImage () from /usr/local/lib/libwebkit-1.0.so.1
#15 0x40cdbb58 in WebCore::GraphicsContext::drawImage () from /usr/local/lib/libwebkit-1.0.so.1
#16 0x40cdbca8 in WebCore::GraphicsContext::drawImage () from /usr/local/lib/libwebkit-1.0.so.1

2- Also i observe that animated gif is much slower than firefox https://bugs.webkit.org/show_bug.cgi?id=7320 is closed but still i see issue on gtk port.
Comment 5 Gustavo Noronha (kov) 2009-03-19 10:15:09 PDT
(In reply to comment #4)
> the animated gif at
> http://content.ytmnd.com/content/6/a/0/6a0e42120c9f9e24dfc3bfa353ccd114.gif
> crashes on my arm build (based on r31307) with the following backtrace

Nor the image in the URL, nor this one crash on my i386 box. Perhaps this is arm-specific? Are you using pre-built packages of a distribution, or building yourself?
Comment 6 Peter Kasting 2009-06-16 22:18:41 PDT
Many different memory problems with the cross-platform GIF decoders were fixed in the last year.  This bug may be obsolete.  It would be nice if anyone could verify that these issues are or are not fixed.
Comment 7 Dirk Schulze 2009-12-01 23:18:22 PST
(In reply to comment #6)
> Many different memory problems with the cross-platform GIF decoders were fixed
> in the last year.  This bug may be obsolete.  It would be nice if anyone could
> verify that these issues are or are not fixed.

Works on latest trunk. No crashes or issues. But it's a i386 build, not a ARM build.
Comment 8 Martin Robinson 2010-05-04 17:51:37 PDT
I'm still seeing issues loading the linked image on a recent checkout (r58781). I'm using the x86_64 GTK+ build on an Ubuntu 9.10 system. With the release build I see corruption (full color noise) while the GIF loads and on the debug build I get a crash like this:

GtkLauncher: Fatal IO error 14 (Bad address) on X server :0.0.

Breakpoint 1, *__GI_exit (status=1) at exit.c:49
49	exit.c: No such file or directory.
	in exit.c
(gdb) where
#0  *__GI_exit (status=1) at exit.c:49
#1  0x00007ffff517b726 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#2  0x00007fffee9a8fae in _XIOError () from /usr/lib/libX11.so.6
#3  0x00007fffee9b09a5 in ?? () from /usr/lib/libX11.so.6
#4  0x00007fffee9b1257 in _XEventsQueued () from /usr/lib/libX11.so.6
#5  0x00007fffee98911a in XFlush () from /usr/lib/libX11.so.6
#6  0x00007ffff5159988 in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0
#7  0x00007ffff5159a39 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#8  0x00007ffff51368c6 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#9  0x00007ffff2f12bce in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#10 0x00007ffff2f16598 in ?? () from /lib/libglib-2.0.so.0
#11 0x00007ffff2f169f5 in g_main_loop_run () from /lib/libglib-2.0.so.0
#12 0x00007ffff54ff177 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#13 0x0000000000400ca5 in main (argc=1, argv=0x7fffffffe248) at ../../WebKitTools/GtkLauncher/main.c:209
Comment 9 Zan Dobersek 2013-03-15 04:16:38 PDT
I can still see animation being corrupted when the GIF is still loading with ToT, using a release build. I'll check for crashes when I have a debug build around.
Comment 10 Simon Pena 2013-07-05 02:26:25 PDT
Created attachment 206129 [details]
Core dump. GtkLauncher, r152392, 64-bit DEBUG build

I just took a quick glance at this, and can confirm what Martin says in comment #8.

If you want to reproduce this in a debug build, using G_SLICE=debug-blocks and MALLOC_CHECK_=2 seems to trigger the X error almost instantly.

I tried with an even larger (in the number of frames) GIF, such as the one in https://bugzilla.mozilla.org/show_bug.cgi?id=523950, which has nearly 9000 frames, and got a segmentation fault instead of an X error: I am attaching a core file for that.

If you try gifs with less frames (100, for example), no error happens. Besides getting the core file, I haven't done any actual progress in the investigation, so feel free to work in this bug.
Comment 11 Anton Obzhirov 2013-07-08 06:57:10 PDT
Some addition from me :).

I did some investigation as well - as far as I can see the problem is when ImageFrame::asNewNativeImage() returns images surface it uses data owned by ImageFrame to back the surface. So if you have void ImageFrame::clearPixelData() called before the data is actually used to draw the image by cairo it might get into trouble. 

if the diff below applied the crush doesn't seem to happen any more even with Simon command line in debug mode.

 PassNativeImagePtr ImageFrame::asNewNativeImage() const
 {
+       cairo_surface_t* surface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, width(), height());
+       unsigned char* data = cairo_image_surface_get_data(surface);
+    memcpy(data, m_bytes, width() * height() * sizeof(PixelData));
+    cairo_surface_mark_dirty(surface);
+    return adoptRef(surface);
-    return adoptRef(cairo_image_surface_create_for_data(
-        reinterpret_cast<unsigned char*>(const_cast<PixelData*>(m_bytes)),
-        CAIRO_FORMAT_ARGB32, width(), height(), width() * sizeof(PixelData)));

Can someone else try this diff to see if it fixes the problem in another environment? If I identified correctly the source of the problem the question is how to fix it properly (may be some by using some reference counting mechanism in frame buffer).
Comment 12 Zoltan Herczeg 2013-07-08 07:14:56 PDT
Could you try the patch here:

https://bugs.webkit.org/show_bug.cgi?id=111179

I think this is the same issue.
Comment 13 Anton Obzhirov 2013-07-08 07:49:15 PDT
(In reply to comment #12)
> Could you try the patch here:
> 
> https://bugs.webkit.org/show_bug.cgi?id=111179
> 
> I think this is the same issue.

sure, I'll do it now.(In reply to comment #12)
> Could you try the patch here:
> 
> https://bugs.webkit.org/show_bug.cgi?id=111179
> 
> I think this is the same issue.

I've tried - it does seem to fix the issue.
Comment 14 Ben Boeckel 2013-08-15 15:31:13 PDT
Possibly related: https://bugzilla.redhat.com/show_bug.cgi?id=981921
Comment 15 Michael Catanzaro 2017-03-06 10:34:40 PST

*** This bug has been marked as a duplicate of bug 111179 ***