[boost] Hangs with Boost 1.56 on clang armhf

Subject: [boost] Hangs with Boost 1.56 on clang armhf
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-07-30 11:47:27

I'm seeing consistent hangs of AFIO on Boost 1.56 on Ubuntu 14.04 LTS 
for clang armhf. GCC armhf works fine, so this is a clang armhf 
related issue.

https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Test%20POSIX_A
RM_clang%203.4/10/console

I talked to Ubuntu upstream about this, and I had the idea of trying 
the LLVM armhf binaries provided at 
http://llvm.org/releases/3.4.2/clang+llvm-3.4.2-armv7a-linux-gnueabihf
.tar.xz as surely LLVM provide good binaries.

Same problem - tests hang. I tried running a test manually and I get 
this:

terminate called after throwing an instance of 
'boost::thread_interrupted'
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively
terminate called recursively

Remember, this is identical code to any other Linux target, plus this 
works a-ok for GCC armhf.

A quick backtrace with gdb reveals this:

terminate called after throwing an instance of 
'boost::thread_interrupted'
[Thread 0xb5b76450 (LWP 12610) exited]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb6376450 (LWP 12609)]
__libc_do_syscall () at 
../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
44      ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No 
such file or directory.
(gdb) bt
#0  __libc_do_syscall () at 
../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
#1  0xb639f0fe in __GI_raise (sig=sig_at_entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0xb63a1956 in __GI_abort () at abort.c:89
#3  0xb65377a8 in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#4  0xb65361c8 in ?? () from 
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt 
stack?)

What looks to be happening here is that thread cancellation, which 
works by having an exception thrown, appears to not be caught by the 
thread being cancelled for some odd reason.

I don't have time to investigate this until maybe Saturday. I guess 
we'll just have to ship 1.56 and look into this for 1.57.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/