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