-----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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYMrgeAAoJEJOUU0jg3ChAopwQAJ+S3WPrCeDP7H+2AEOH3Veu 2KceQvYbsdOa8bextckXoZLcB0vlxNAMblk1OlbpYt2gR3PPtl7zo6yVpoXdLpAt gXIHPA2NLGdJn+mA+4S74Jxai2I3NgE7g2/In3li5Fz5UWd4BUKkwFP6PJ98KBum DFdst1KdLeUXTCmVI5w5AMJ9Ht+Jmo0VIqNd5b3H5oND6ublo/WlW69U3CXq/mgx +NAzJ7QY3bWs5DmVu8IO19msCwcjzj+B8YpVUr6awuwU+ltAZOeXh/EK5vIliK/D VYcz8YcDeWj1AAYamjq7JHE4KUk2qjv2IaETFB5gt6u56zinTxxxRjUozL2ey/tc +zbbC0MamxoeP3ouwDmRDo7i9RFZPKsB1JOzdcIfZvczOkglQEBPwR+q6X3ooZPP zVQVJY/RdY/2U4/QCcWB6DBPxkRu4Gx3bwY8Twaq2LqtRgMdw+NO/hFNovMkm54g UgXA3NMHmt1IUL6AKFdeQewKunNXsgN/+v/ysxkwXvlSwmAlWxdB4+x0P1CcxzPJ v47T/gv2lrCd0JMoMWjEG7hIhOYP9Hr6J4dFSwUmsdmhfeZAXZmbfN090dZJNvu6 3PYC/QxgNk/rgC3k2S6g3zWqz6rpWbVkONIzokL2wknWmYtaOc6FsRaGfsDu792N ZzLWeBSV2egLCqdFnQjG =yU0n -----END PGP SIGNATURE-----
