[pkg-boost-devel] Bug#844495: Bug#844495: Bug#844490: FTBFS with boost1.62

Mon Nov 21 09:02:22 UTC 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear Steve,

thanks for your answer:

Le 20/11/2016 à 05:12, Steve M. Robbins a écrit :
> On Wednesday, November 16, 2016 12:16:22 PM CST Thibaut Paumard
> wrote:
>> I've realized that, when acos() does not return, delta100 above
>> is always zero. I can simplify the case by simply doing 
>> acos(cos(alpha100))
>> 
>> in which case acos() also does not return. Does not look like a
>> memory leak after all.
>> 
>> However, doing just that in an isolated main function does not
>> exhibit the bug (I've also tried activating all the hardening
>> features)
> 
> So when you say "doing just that" in isolated main ... do you mean 
> doing acos(cos(alpha100)*cos(delta100)) or acos(cos(alpha100))?

The minimal test that I tried (and that does not demonstrate the bug)
is attached below. I was not yet able to make a small test case that
exhibits the bug. I'll have to start from the full program and un-knit i
t.

I've been able to gather more information though:

  - the initial failure occurred in a unit test where the Gyoto
library is used through an interpreted language (Yorick); now I have
been able to exhibit the bug also from the main gyoto executable by
increasing the resolution of the raytracing test and making it odd
(101 instead of 32) so that the ray-tracing at delta=0 occurs.

  - this indicates that even more architectures are affected. amd64
and i386 seem not to be. The complete list of architectures on which I
have been able to trigger the problem is: arm64 armel armhf mips64el
ppc64el s390x powerpc ppc64.

  - when failure occurs, delta seems to always be 0, but the reverse
is not true (sometimes delta is 0 ans acos() does not lock).

  - increasing the number of digits makes the bug bite earlier.

  - although I haven't read it in full yet, there is a thread on
debian-devel mentioning hardening of pthread locking in libc. Gyoto
does use pthreads (although the bug also shows up when using a single
thread). I'd like to see whether the bug is triggered this libc change
instead of the new version of boost, but I think I need to recompile
the older boost on a porterbox with the new libc to try this. It will
take some time, as my day job also needs attention.

  - rebuilding with boost1.62 on alpha also fails (which is also a
regression) with a different symptom, which may or may not be related:

/usr/bin/ld: .libs/Screen.o: dtp-relative relocation against dynamic
symbol
_ZGVZN5boost14multiprecision11default_ops15get_constant_piINS0_8backends
13cpp_dec_floatILj100EivEEEERKT_vE6result

https://buildd.debian.org/status/fetch.php?pkg=gyoto&arch=alpha&ver=1.1.
1-3&stamp=1479433143

Test case that does not demonstrate the bug:
8<--------------8<------------8<
#include <boost/multiprecision/cpp_dec_float.hpp>
#include <iostream>

int main(int argc, char ** argv) {

  double alpha=0.5, delta=0.;

boost::multiprecision::number<boost::multiprecision::cpp_dec_float<100>
>
    alpha100=alpha, delta100=delta, a;
  a=acos(cos(alpha100));

  std::cerr << a << std::endl;

  return 0;
}
8<--------------8<------------8<

Kind regards, Thibaut.