[webkit-dev] Crash on xLarge memory allocation using bmalloc on 32bit systems

[Mario Sanchez Prada]

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