verrou 2.1.0 + glibc 2.27's "pow" = segfault
Closed this issue · 1 comments
HadrienG2 commented
I am aware that running the libm under verrou is bound to produce all sorts of weird results, but I suspect segfaulting is not an expected outcome and might hint at a deeper problem.
#include <cmath>
#include <iostream>
int main() {
volatile double argument = 0.43312570424167907;
std::cout << (double) std::pow(argument, 0.25) << std::endl;
}
hadrien@linux-2ak3:~/Bureau/test> valgrind --tool=verrou --rounding-mode=farthest ./a.out
==2326== Verrou, Check floating-point rounding errors
==2326== Copyright (C) 2014-2016, F. Fevotte & B. Lathuiliere.
==2326== Using Valgrind-3.14.0+verrou-2.1.0 and LibVEX; rerun with -h for copyright info
==2326== Command: ./a.out
==2326==
==2326== Backend verrou : 1.x-dev
==2326== Simulating FARTHEST rounding mode
==2326== Instrumented operations :
==2326== add : yes
==2326== sub : yes
==2326== mul : yes
==2326== div : yes
==2326== mAdd : yes
==2326== mSub : yes
==2326== cmp : no
==2326== conv : yes
==2326== max : no
==2326== min : no
==2326== Instrumented scalar operations : no
==2326==
==2326== Process terminating with default action of signal 11 (SIGSEGV)
==2326== Access not within mapped region at address 0x5737978
==2326== at 0x4AA6D8B: __ieee754_pow_fma (e_pow.c:415)
==2326== by 0x4A36773: pow (w_pow_compat.c:30)
==2326== by 0x401198: main (in /home/hadrien/Bureau/test/a.out)
==2326== If you believe this happened as a result of a stack
==2326== overflow in your program's main thread (unlikely but
==2326== possible), you can try to increase the size of the
==2326== main thread stack using the --main-stacksize= flag.
==2326== The main thread stack size used in this run was 8388608.
==2326==
==2326== ---------------------------------------------------------------------
==2326== Operation Instruction count
==2326== `- Precision
==2326== `- Vectorization Total Instrumented
==2326== ---------------------------------------------------------------------
==2326== add 30 30 (100%)
==2326== `- dbl 30 30 (100%)
==2326== `- llo 30 30 (100%)
==2326== ---------------------------------------------------------------------
==2326== sub 23 23 (100%)
==2326== `- dbl 23 23 (100%)
==2326== `- llo 23 23 (100%)
==2326== ---------------------------------------------------------------------
==2326== mul 23 23 (100%)
==2326== `- dbl 23 23 (100%)
==2326== `- llo 23 23 (100%)
==2326== ---------------------------------------------------------------------
==2326== mAdd 10 10 (100%)
==2326== `- dbl 10 10 (100%)
==2326== `- llo 10 10 (100%)
==2326== ---------------------------------------------------------------------
==2326== cmp 7 0 ( 0%)
==2326== `- dbl 7 0 ( 0%)
==2326== `- scal 7 0 ( 0%)
==2326== ---------------------------------------------------------------------
==2326== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Erreur de segmentation (core dumped)
Excluding the __ieee754_pow_fma
symbol from the libm will make the segfault go away.
lathuili commented
This result is badly expected. Indeed the perturbation of the argument reduction can produce wrong income value for the interpolation table and so sometimes a segfault. That's why it's highly suggested to exclude libm. If you want to see the impact of libm rounding, verrou proposes an experimental interposition perturbed libm called Interlibmath. It's not yet really user-friendly.