valgrind investigations about wide-integer HOT 6 CLOSED

Be sure to compile with WIDE_INTEGER_HAS_COVERAGE which (even though intended for coverage runs) drastically reduces the number and scope of test cases. This makes a slow valgrind run feasible on GHA pipelines.

The first local valgrind run was very satisfying. See report below.

==4353==
==4353== HEAP SUMMARY:
==4353==     in use at exit: 0 bytes in 0 blocks
==4353==   total heap usage: 15,124,969 allocs, 15,124,969 frees, 7,127,874,355 bytes allocated
==4353==
==4353== All heap blocks were freed -- no leaks are possible
==4353==
==4353== For lists of detected and suppressed errors, rerun with: -s
==4353== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

from wide-integer.

TBD: Add valgrind run to CI and check (via, for instance, grep) for:

ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

from wide-integer.

from wide-integer.

Hi John (@johnmcfarlane) it is good to hear from you.

Locally, I get 0 bytes missing in any way on valgrind. And I also see no problems whatsoever with ASAN (i.e., address sanitize runs). So these are consistent.

However, uggghhhh. I am struggling at the moment as well on the runners. I did get one successful valgrind run on the pipeline but now I get a very curious core dump.

So I'm not sure yet if valgrind actually adds any value.

from wide-integer.

Hi John (@johnmcfarlane) I was curious about this valgrind. I think remember it came out after I had finished heavy numerics in grad school on FORTRAN in the 80s. Then when I was long out of numerics, I heard some chatter about it. Now it looks like it's supported so I thought I'd investigate it.

I'll keep you posted. I also ran across a POSIX sync checker calld helgrind. I do not know if that adds anything beyod TSAN?

from wide-integer.

found ASan generally a lot easier to work with

Yes John (@johnmcfarlane) I just empirically stumbled across a problem running valgrind on GHA Ubuntu runners. It seems like valgrind consistently core dumps on certain code sequences compiled with -march=native and/or -mtune= native. So I worked around this with the more vanilla tuning -m64.

I think I will, in fact, retain the valgrind run. Although it does not seem to really find anything that ASAN didn't find, I think I'll keep it going for a while on the nightly, but I'll freeze in on something like GCC-12.

But I'm watchful of it. If valgrind ever causes big problems, I'll eliminate it's use on the pipelines.

from wide-integer.