Bug 157029 – [GTK] 2.12.1 fails to build in powerpc if bmalloc is enabled

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Alberto Garcia]

The build fails when /usr/bin/g-ir-scanner is called to generate WebKit2-4.0.gir.

Command '[u'webkit2gtk-2.12.1/obj-powerpc-linux-gnu/Source/WebKit2/tmp-introspectFlcmnB/WebKit2-4.0', u'--introspect-dump=webkit2gtk-2.12.1/obj-powerpc-linux-gnu/Source/WebKit2/tmp-introspectFlcmnB/functions.txt,webkit2gtk-2.12.1/obj-powerpc-linux-gnu/Source/WebKit2/tmp-introspectFlcmnB/dump.xml']' returned non-zero exit status -11

Here's the backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0c1eb8a0 in bmalloc::List<bmalloc::SmallPage>::remove () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/List.h:86
86              ListNode<T>* next = node->next;
(gdb) bt
#0  0x0c1eb8a0 in bmalloc::List<bmalloc::SmallPage>::remove () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/List.h:86
#1  0x0c1eb16c in bmalloc::List<bmalloc::SmallPage>::pop () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/List.h:61
#2  0x0c1e5eec in operator() () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/Heap.cpp:299
#3  0x0c1e6008 in bmalloc::Heap::allocateSmallPage () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/Heap.cpp:303
#4  0x0c1e6598 in bmalloc::Heap::allocateSmallBumpRangesByMetadata () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/Heap.cpp:338
#5  0x0c1e2800 in bmalloc::Heap::allocateSmallBumpRanges () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/Heap.h:125
#6  0x0c1e1564 in bmalloc::Allocator::refillAllocatorSlowCase () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/Allocator.cpp:182
#7  0x0c1e1904 in bmalloc::Allocator::refillAllocator () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/Allocator.cpp:189
#8  bmalloc::Allocator::allocateSlowCase () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/Allocator.cpp:225
#9  0x0c16986c in bmalloc::Allocator::allocate () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/Allocator.h:86
#10 0x0c1e3120 in bmalloc::Cache::allocateSlowCaseNullCache () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/Cache.cpp:66
#11 0x0c169b14 in bmalloc::Cache::allocate () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/Cache.h:78
#12 0x0c169ff0 in bmalloc::api::malloc () at webkit2gtk-2.12.1/Source/bmalloc/bmalloc/bmalloc.h:43
#13 0x0c168e58 in WTF::fastMalloc () at webkit2gtk-2.12.1/Source/WTF/wtf/FastMalloc.cpp:193
#14 0x0be7b000 in WTF::StringImpl::operator new () at webkit2gtk-2.12.1/Source/WTF/wtf/text/StringImpl.h:132
#15 0x0c1ad888 in WTF::StringImpl::createFromLiteral () at webkit2gtk-2.12.1/Source/WTF/wtf/text/StringImpl.cpp:146
#16 0x0c1ad924 in WTF::StringImpl::createFromLiteral () at webkit2gtk-2.12.1/Source/WTF/wtf/text/StringImpl.cpp:151
#17 0x0c1c2fb4 in WTF::String::String () at webkit2gtk-2.12.1/Source/WTF/wtf/text/WTFString.cpp:86
#18 0x0f5efd3c in __static_initialization_and_destruction_0 ()
    at webkit2gtk-2.12.1/Source/WebCore/platform/gtk/PasteboardHelper.cpp:44
#19 0x0f5efd90 in _GLOBAL__sub_I_PasteboardHelper.cpp(void) ()
    at webkit2gtk-2.12.1/Source/WebCore/platform/gtk/PasteboardHelper.cpp:329
#20 0xf7fb07f8 in ?? () from /lib/ld.so.1
#21 0xf7fb0964 in ?? () from /lib/ld.so.1

[Alberto Garcia]

For the record, it seems that 2.12.0 built fine in the same platform, so maybe this is a regression in bmalloc.

Full log here (WARNING: 45 MB text file):

https://buildd.debian.org/status/fetch.php?pkg=webkit2gtk&arch=powerpc&ver=2.12.0-2%2Bb1&stamp=1460126158

[Carlos Alberto Lopez Perez]

You can set the environment variable Malloc=1 to disable bmalloc at run-time.

Is the crash still reproducible if you export this variable ?

bmalloc has a tendency to crash when there isn't enough memory on the system.

If after disabling bmalloc you now observe an OOM situation instead of a crash then it probably indicates that the system don't has enough memory or a memory leak somewhere in the build process or in webkit.

[Alberto Garcia]

(In reply to comment #2)
> You can set the environment variable Malloc=1 to disable bmalloc at run-time.
>
> Is the crash still reproducible if you export this variable ?

No, it no longer crashes.

[Carlos Alberto Lopez Perez]

I see that there has been quite a number of changes in bmalloc from 2.12.0 to 2.12.1.

From 2.12.0 to 2.12.1

$ git log f8a7002297635bc5a1da2fe6a2fb7d6703e4b8d5..fed3decfadde70b21c17f6865d21da7b06d2f15f --oneline Source/bmalloc/
3dd2907 Merge r199246 - bmalloc: stress_aligned test fails if you increase smallMax https://bugs.webkit.org/show_bug.cgi?id=156414
d1544fd Merge r199115 - bmalloc: handle aligned allocations on the fast path https://bugs.webkit.org/show_bug.cgi?id=156302
f7ab636 Merge r198995 - bmalloc: segregate small and large objects again, and allocate more objects on the small path https://bugs.webkit.org/show_bug.cgi?id=156152
439de42 Merge r198829 - bmalloc: support physical page sizes that don't match the virtual page size (take 2) https://bugs.webkit.org/show_bug.cgi?id=156003
c7c8df5 Merge r198821 - bmalloc: page size should be configurable at runtime https://bugs.webkit.org/show_bug.cgi?id=155993
adbd625 Merge r198809 - bmalloc: add logging for mmap() failures <http://webkit.org/b/155409> <rdar://problem/24568515>
0ebd1f2 Merge r198680 - bmalloc: stress_aligned fails when allocating a zero-sized object with XLarge alignment https://bugs.webkit.org/show_bug.cgi?id=155896
ecc5aed Merge r198693 - Unreviewed, try to fix a crash seen on the bots.
c581e56 Merge r198679 - bmalloc: Renamed LargeChunk => Chunk https://bugs.webkit.org/show_bug.cgi?id=155894
057e3b4 Merge r198675 - bmalloc: small and large objects should share memory https://bugs.webkit.org/show_bug.cgi?id=155866
59418bc Merge r198606 - bmalloc: Added an Object helper class https://bugs.webkit.org/show_bug.cgi?id=155818
27c55de Merge r198594 - bmalloc: process the object log before asking for new memory https://bugs.webkit.org/show_bug.cgi?id=155801
5381a78 Merge r198571 - bmalloc: use a log scale for large-ish size classes https://bugs.webkit.org/show_bug.cgi?id=155770
4a5efd2 Merge r198545 - bmalloc: shrink largeMax https://bugs.webkit.org/show_bug.cgi?id=155759


From 2.12.1 to current unreleased HEAD for 2.12.x

$ git log fed3decfadde70b21c17f6865d21da7b06d2f15f..HEAD --oneline Source/bmalloc/
b5558ad Merge r199759 - bmalloc: fix up overflow checks https://bugs.webkit.org/show_bug.cgi?id=156780
3d0e906 Merge r199756 - Unreviewed, try to fix an ASSERT seen on the bots.
b1e58d5 Merge r199746 - bmalloc: Merge the large and xlarge allocators https://bugs.webkit.org/show_bug.cgi?id=156734



I guess that someone with access to a PowerPC machine should try to do a bisect and identify the bad commit.

[Michael Catanzaro]

(In reply to comment #4)
> I guess that someone with access to a PowerPC machine should try to do a
> bisect and identify the bad commit.

Seems aarch64 is also affected.

[Alberto Garcia]

(In reply to comment #5)
> (In reply to comment #4)
> > I guess that someone with access to a PowerPC machine should try to do a
> > bisect and identify the bad commit.
> 
> Seems aarch64 is also affected.

Is it? It seems to work fine for me

$ uname -a
Linux asachi 3.16.0-4-arm64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) aarch64 GNU/Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/5/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-16' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-arm64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-arm64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-arm64 --with-arch-directory=aarch64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-multiarch --enable-fix-cortex-a53-843419 --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160424 (Debian 5.3.1-16)

[Alberto Garcia]

(In reply to comment #4)
> $ git log fed3decfadde70b21c17f6865d21da7b06d2f15f..HEAD --oneline Source/bmalloc/
> b5558ad Merge r199759 - bmalloc: fix up overflow checks https://bugs.webkit.org/show_bug.cgi?id=156780

The 2.12.x HEAD is no longer broken, likely the above commit fixed the problem.

[Michael Catanzaro]

(In reply to comment #6)
> Is it? It seems to work fine for me

I would assume so, that Red Hat #1330466 sounds awfully similar (crash when building the documentation in 2.12.1, worked fine in 2.12.0).

[Tomas Popela]

(In reply to comment #8)
> (In reply to comment #6)
> > Is it? It seems to work fine for me
> 
> I would assume so, that Red Hat #1330466 sounds awfully similar (crash when
> building the documentation in 2.12.1, worked fine in 2.12.0).

And the backtrace is the same..