[C++] Reenable Valgrind on Travis-CI

[asfimport]

Running Valgrind on Travis-CI was disabled in ARROW-4611 (apparently because of issues within the re2 library).

We should reenable it at some point in order to exercise the reliability of our C++ code.
(and/or have a build with another piece of instrumentation enabled such as ASAN)

Reporter: Antoine Pitrou / @pitrou

Related issues:

• [C++] [Gandiva] JIT code executed over uninitialized values (depends upon)
• [C++] Valgrind failures in JSON tests (depends upon)

_{Note: This issue was originally created as ARROW-5270. Please see the migration documentation for further details.}

[asfimport]

Antoine Pitrou / @pitrou:
@xhochy

[asfimport]

Pindikura Ravindra / @pravindra:
There are two issues :

1. instructions not recognized by valgrind

   =20276== Your program just tried to execute an instruction that Valgrind ==20276== did not recognise. There are two possible reasons for this. ==20276== 1. Your program has a bug and erroneously jumped to a non-code ==20276== location. If you are running Memcheck and you just saw a ==20276== warning about a bad jump, it's probably your program's fault.

   2. the re2 issues

   I think these are already covered by the suppressions listed in the valgrind.supp but they aren't being recognized due to missing symbols in the stack. 

   When I ran this on my xenial setup without any conda setup, the stacks showed up correctly and got suppressed. so, I suspect this is an issue with conda binaries.

[asfimport]

Pindikura Ravindra / @pravindra:
https://travis-ci.org/apache/arrow/jobs/531878628

[asfimport]

Antoine Pitrou / @pitrou:
The instructions not recognized seem to be SSE4.2 instructions. We would probably need a more recent Valgrind version on Travis-CI...

[asfimport]

Antoine Pitrou / @pitrou:
We now test with ASAN and UBSAN on Travis, so perhaps this is not as important as it used to be. @wesm [~emkornfield@gmail.com] opinions?

[asfimport]

Wes McKinney / @wesm:
I'd be okay relegating valgrind testing to docker-compose

[asfimport]

Micah Kornfield / @emkornfield:
I think the one thing missing from UBSan/ASAN that I know of that has some utility is making use of uninitialized memory. For that we would need to enable MSan which I don't think is practical. But I agree we should catch a large class of errors with current sanitizers.

[asfimport]

Antoine Pitrou / @pitrou:
I'm not sure we'll ever re-enable Valgrind. Micah, what do you think? Should we close this issue?

[asfimport]

Wes McKinney / @wesm:
I'd prefer to run valgrind builds only in Docker (e.g. so they can be run on-demand on Ursabot, much faster)

[asfimport]

Antoine Pitrou / @pitrou:
Ok, let's close this issue then.