Hi all, As I already reported last week in webkit-gtk[1], I've been reliably seeing a crash in bmalloc lately in my 32bit Linux system every single time I run a specific Webkit-based app, after upgrading from WebKitGTK+ 2.6.2 to 2.8.3.
See below and excerpt of the best backtrace I could get (see the full one in http://lists.webkit.org/pipermail/webkit-gtk/2015-June/002381.html): (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 [...] Also, according to Red Hat bugzilla's bug 1225733 [2], it seems I'm not the only one getting the crash, since it has been reported more than 105 times in Fedora now (always for 32bit systems too), and I wonder whether this might be an issue for other ports too, such as Apple or EFL. For what it's worth, and in case you want to try this out yourself too, I can now reproduce this bug also simply by loading this URL on Minibrowser: http://crucial.tmall.com/category-988709636.htm?utm_source=baidu&utm_medium=ppc&utm_term=6.18&utm_content=general&utm_campaign=s_mx100 Last, I initially thought this might be related to WK bug 145385 (integer overflow), but turned out not to be the case, so I reported a new one: https://bugs.webkit.org/show_bug.cgi?id=146440 If you check my last comments in there, you will see that I found out that passing -fno-tree-sra to gcc while compiling would reliably prevent the crash from happening, both in my use case and when using the URL above. Does anyone here have any idea why this could be the case? Any hint? While passing -fno-tree-sra could be an interesting temporary workaround (specially if constrained in scope to bmalloc only) for downstream, it does feel like papering over the real issue, which could still be there in WK. Thanks, Mario [1] https://lists.webkit.org/pipermail/webkit-gtk/2015-June/002381.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1225733 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
