Bug 16200

Commit r28345 fixed the image corruption issues by removing a misplaced 'delete'. The crashes are still unresolved.

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

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.

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.

(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?

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.

(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.

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

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.

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.

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).

Could you try the patch here: https://bugs.webkit.org/show_bug.cgi?id=111179 I think this is the same issue.

(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.

Possibly related: https://bugzilla.redhat.com/show_bug.cgi?id=981921

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