On Wed, Jun 24, 2015, at 06:05 PM, Mario Sanchez Prada wrote: > Hi all, > > I've recently upgraded the version of WebKitGTK+ in our platform from > 2.6.4 to 2.8.3 and, quite surprisingly, it crashes now when used from > some of the components that embed WebKit, without any other change in > the system other than that one. >
Any reproducible test case, perhaps on a public Web page? Cheers, Zan > More specifically, this is an excerpt of the backtrace I'm seeing > (full backtrace attached): > > (gdb) bt > #0 allocateXLarge () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/Heap.cpp:287 > #1 0xb4fc94f5 in allocateXLarge () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/Heap.cpp:293 > #2 0xb4fc6ac4 in allocateXLarge () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/Allocator.cpp:227 > #3 0xb4fc6b2e in allocateSlowCase () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/Allocator.cpp:245 > #4 0xb4f95de2 in allocate () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/Allocator.h:86 > #5 allocate () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/Cache.h:79 > #6 malloc () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/bmalloc/bmalloc/bmalloc.h:43 > #7 fastMalloc () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/FastMalloc.cpp:270 > #8 0xb5592815 in allocateBuffer () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/Vector.h:269 > #9 reserveCapacity () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/Vector.h:1090 > #10 expandCapacity () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/Vector.h:951 > #11 0xb5f766e1 in expandCapacity () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/Vector.h:958 > #12 appendSlowCase<WebCore::FloatRect&> () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/Vector.h:1219 > #13 append<WebCore::FloatRect&> () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WTF/wtf/Vector.h:1210 > #14 createOrDestroyTilesIfNeeded () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WebCore/platform/graphics/texmap/TextureMapperTiledBackingStore.cpp:89 > #15 0xb5f77001 in updateContents () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WebCore/platform/graphics/texmap/TextureMapperTiledBackingStore.cpp:148 > #16 0xb64aefb3 in updateBackingStoreIfNeeded () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:549 > #17 0xb64af095 in updateBackingStoreIncludingSubLayers () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:519 > #18 0xb64af0ed in updateBackingStoreIncludingSubLayers () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:526 > #19 0xb64af0ed in updateBackingStoreIncludingSubLayers () at > /home/mario/webkit2gtk-2.8.3+dfsg1/Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:526 > [...] > > I've taken a look to the latest commits in trunk and even blindly > applied the patch "Integer overflow in XLarge allocation (due to > unchecked roundUpToMultipleOf)" (from bug 145385 [1]), but that did > not work. For some reason I yet have not identified, the call to > tryAllocateXLarge() from bmalloc::Heap::allocateXLarge() is returning > NULL while in the process of updating the tiles in the backing store, > but I believe this should not cause an OOM so I'm a bit confused now. > > Does anyone here perhaps have any idea of what could be going on here? > If so, I would certainly appreciate some help :) > > Thanks in advance, > Mario > > [1] https://bugs.webkit.org/show_bug.cgi?id=145385 > _______________________________________________ > webkit-gtk mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-gtk > Email had 1 attachment: > + crash > 7k (application/octet-stream) _______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
