Hartmut Kaiser

From what I see, those are mostly `std::bad_alloc` exception being thrown. This should be easy enough to find.

> Would it make sense to build them with the system allocator instead of TCMalloc? @khuck that would be worth a try. God knows, tcmalloc might be broken on Power.

@khuck Same game: could you get gdb stack backtraces for the `std::bad_alloc` that is thrown?

@khuck, so it's a blaze bug as it seems to wrongly detect the alignment size. Blaze might not even support Power ;-) I'll ask

@khuck Blaze determines the alignment for a given type `T` from `std::alignment_of::value` (https://bitbucket.org/blaze-lib/blaze/src/b742cdd522a0bf0c4c578bdf2ec3a7d5f40ec910/blaze/util/typetraits/AlignmentOf.h?at=master&fileviewer=file-view-default#AlignmentOf.h-67), which looks like the right thing to do. The failing allocation tries to allocate `std::uint8_t`s (see: https://github.com/STEllAR-GROUP/phylanx/blob/master/tests/unit/plugins/booleans/unary_not_operation.cpp#L88),...

@khuck could you set a breakpoint at the line in the test (see above) and see what arguments the `posix_memalign` (https://bitbucket.org/blaze-lib/blaze/src/b742cdd522a0bf0c4c578bdf2ec3a7d5f40ec910/blaze/util/Memory.h?at=master&fileviewer=file-view-default#Memory.h-90) is invoked with?

@khuck so the minimal alignment on Power is `8`, no matter what? Why does `std::alignment_of::value` return 4, then? This doesn't make sense. Or the left hand (Posix) doesn't know what...

FWIW, here is @khuck's patch (blaze/util/Memory.h at line 91): ``` 79 inline byte_t* allocate_backend( size_t size, size_t alignment ) 80 { 81 void* raw( nullptr ); 82 83 #if BLAZE_WIN64_PLATFORM...

This is an HPX problem. I created a ticket here: STEllAR-GROUP/hpx#5118.

@stevenrbrandt would you be able to show the back-traces for all threads? the one above is not from the thread that fails.