Boost C++ Libraries: Ticket #10005: erf_inv_initializer crashes under valgrind

John Maddock — Sun, 04 May 2014 16:24:17 GMT

Oh boy this sucks :-(

You could work around the problem by defining BOOST_MATH_PROMOTE_DOUBLE_POLICY=false when building I guess.

I don't really understand why this is being triggered, the code checks that 1e-800 is non-zero before calling erc_inv(1e-800) at which point it apparently is zero after all! The argument values can't be changed BTW - they're cunningly chosen to take specific code paths and force initialization of all the static data. Or I could add some try/catch blocks I guess, I will probably experiment with that.

anonymous — Sun, 04 May 2014 17:36:35 GMT

Update: I just experimented with this, and I'm unable to reproduce with current Git master and valgrind-3.8.1. Do you have a reduced test case?

Sun, 04 May 2014 23:27:51 GMT

I haven't realized it before, but it depends on compiler flags. I'm using now Fedora 20, valgrind 3.9.0, GCC 4.8 and boost 1.54 and 1.55 (both give the same result). I can reproduce the problem only with g++ -Og.

But I've seen it with previous GCC versions (4.6 or 4.7, I'm not sure) and valgrind 3.8.1. I don't remember what optimization flags I used, but there was no -Og in previous versions.

The minimal program I now use for testing is:

#include <stdio.h>
#include <stdlib.h>
#include <boost/math/special_functions.hpp>
int main(int argc, char **argv) {
    double x = strtod(argv[1], NULL);
    printf("%g\n", boost::math::erfc_inv(x));
}

So as a workaround I'll just use a different compilation flags.

status changed; resolution set

John Maddock — Mon, 26 May 2014 18:23:35 GMT

status new → closed
resolution → fixed

It does indeed seem to be specific to using -Og. After a bit of experimentation I believe I have it fixed in https://github.com/boostorg/math/commit/a29a74bdaf078b5df4f875ead18960671fd5c479

jon.gammell@… — Fri, 17 Jul 2015 18:47:49 GMT

I am experiencing this on Ubuntu 12.04 (valgrind-3.7.0 and gcc 4.6.3) with a manually installed Boost 1.58.0.

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::overflow_error> >'
  what():  Error in function boost::math::erfc_inv<long double>(long double, long double): Overflow Error

It occurs when either the -O3 or -O2 flag is given, but does not occur without an -O flag. I didn't test any other optimization flag combinations.

John Maddock — Fri, 17 Jul 2015 19:00:19 GMT

Sigh... I'll look into this again, but no promises, long double floating point values seem to behave completely unpredictably under valgrind :(

Tue, 10 Nov 2015 20:21:06 GMT

I was hit by this problem using Ubuntu 15.10 LTS on x86-64, which ships with boost 1.58.0 and GCC 5.2.1. For me, this problem exists only when my program is compiled by using -O2 -g. It ran ok under valgrind when compiled without -O2. I guess GCC removes is_value_non_zero() during optimization.

status changed; resolution deleted

scott_paulin@… — Tue, 19 Jan 2016 22:38:52 GMT

status closed → reopened
resolution fixed

I am getting this under boost version 1.54.0.1 installed from apt-get on Mint 17.2. Compiled with clang 3.4. Still occurs when no build flags are specified.

anonymous — Wed, 20 Jan 2016 03:33:12 GMT

Replying to scott_paulin@…:

I am getting this under boost version 1.54.0.1 installed from apt-get on Mint 17.2. Compiled with clang 3.4. Still occurs when no build flags are specified.

Update: Works fine when I compile my code WITHOUT -std=c++11

anonymous — Wed, 20 Jan 2016 03:36:06 GMT

Replying to anonymous:

Replying to scott_paulin@…:

I am getting this under boost version 1.54.0.1 installed from apt-get on Mint 17.2. Compiled with clang 3.4. Still occurs when no build flags are specified.

Update: Works fine when I compile my code WITHOUT -std=c++11

Sorry, the first message should have read "Still occurs when no -O build flags are specified". I can't edit that message, it would be cool if someone with admin rights could clean up my mess by editing my first message.

anonymous — Wed, 20 Jan 2016 11:53:14 GMT

Boost-1.54 is an old Boost release now - and precedes the fixes (such as they are) above. Can you please try with Boost-1.60?

John Maddock — Thu, 21 Jan 2016 11:08:28 GMT

I'm unable to reproduce on ubuntu with any combination of -ON and -g and either latest clang or gcc-5.1 or 4.9.2 and current develop branch (which should be the same as 1.60). Which is not to say that some folks won't experience this still.

The essential issue is that valgrind doesn't support long double fully, so finite long doubles can get truncated to zero or infinity and random points in the program (ie you can check that a variable is non-zero, and then in the next line when you go to actually use it, it's been magically truncated to zero. The result is that it completely breaks program logic).

There are a couple of possible workarounds (other than choosing -O options carefully), to define:

BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS - which prevents any long double functions from being defined or used with Boost.Math, or else define: BOOST_MATH_PROMOTE_DOUBLE_POLICY=false, which prevents double functions from being evaluated at long double precision internally, but otherwise retains the long double implementations if they're needed.

Both of these will reduce precision slightly, and both will typically improve performance on 64-bit hardware.

anonymous — Wed, 05 Oct 2016 08:42:36 GMT

We have this problem using boost 1.60. Is there any work around?

anonymous — Fri, 21 Apr 2017 11:42:21 GMT

I still have this problem with boost 1.64.

anonymous — Fri, 21 Apr 2017 11:42:52 GMT

I still have this problem with boost 1.64.

John Maddock — Sat, 22 Apr 2017 11:27:45 GMT

I'm unable to reproduce, I tried every combination of -std= and -O options I could think of with gcc-4.8.4, 6.1.0 and clang-5.

Can you provide an updated test case along with the build options and compiler version used?

anonymous — Tue, 29 Aug 2017 09:38:56 GMT

Reproduced under Ubuntu 17.04

$ valgrind --version valgrind-3.13.0

$ gcc --version gcc (Ubuntu 7.2.0-1ubuntu2) 7.2.0
I use both -std=c++11 and -O2 flags and valgrind works fine if I remove the -O flag

Tom Anderson — Tue, 31 Oct 2017 15:44:57 GMT

I appear to have this with valgrind 3.10.1, and Boost 1.63.0, compiled with GCC 7.2.0 on Ubuntu 14.04.5.

I'm not sure what compiler flags i'm using: Boost is a dependency of a third-party library whose build process is an impenetrable thicket.