1

I'm using a proprietary library to import data, it uses the GPU (OpenGL) to transform the data. Running my program through Valgrind (memcheck) causes the data import to take 8-12 hours (instead of a fraction of a second). I need to do my Valgrind sessions overnight (and leave my screen unlocked all night, since the GPU stuff pauses while the screen is locked). This is causing a lot of frustration.

I'm not sure if this is related, but Valgrind shows thousands of out-of-bound read/write errors in the driver for my graphics card:

==10593== Invalid write of size 4
==10593==    at 0x9789746: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)

(I know how to suppress those warnings).

I have been unable to find any ways of selectively instrumenting code, or excluding certain shared libraries from being instrumented. I remember using a tool on Windows 20 years or so ago that would skip instrumenting selected binaries. It seems this is not possible with memcheck:

...unless things have changed in the last 6 or 7 years.

My question is: Is there anything at all that can be done to speed up the memory check? Or to not check memory accesses in certain parts of the program?

Right now the only solution I see is to modify the program to read data directly from disk, but I'd rather test the actual program I'm planning to deploy. :)

Cris Luengo
  • 55,762
  • 10
  • 62
  • 120
  • 1
    Look into the Clang Sanitizers (many of which have been ported to gcc) – Justin Mar 30 '18 at 20:08
  • 1
    Yeah, Valgrind is *slow*. Mayby look into the llvm sanitizers - like address sanitizer, undefined behaviour sanitizer etc.. there are quite a few and they are faster and (IMHO) a lot better than Valgrind. – Jesper Juhl Mar 30 '18 at 20:10
  • Indeed, both GCC and CLang support a `-fsanitize=address` option. And it works great. It only instruments the code you build with the flag, so it can be used selectively. Of course there is no way of instrumenting code you can't build yourself, but that is precisely what I was looking for. :) – Cris Luengo Mar 31 '18 at 00:43

1 Answers1

1

No, this is not possible. When you run an application under Valgrind it is not running natively under the OS but rather in a virtual environment.

Some of the tools like Callgrind have options to control the instrumentation. However, even with the instrumentation off the application under test is still running under the Valgrind virtual environment.

There are a few things you can do to make things less slow

  • Test an optimized build of your application. You will lost line number information as a result, however.
  • Turn of leak detection
  • Avoid costly options like trace-origins

The sanitizers are faster and can also detect stack overflows, but at the cost of requiring instrumentation.

Paul Floyd
  • 5,530
  • 5
  • 29
  • 43
  • Thanks. I will try turning off leak detection and so forth. The optimized build I don't expect to change anything because the library that does the data import I don't compile myself, it's already optimized. And that is where this big slowdown occurs. – Cris Luengo Mar 31 '18 at 16:55
  • Disabling trace-origins and leak detection does speed up the execution significantly, but the portion of the program where I call the external library to fetch data (which uses OpenGL internally) still takes upwards of an hour rather than a fraction of a second. I've been using the sanitizers instead of valgrind. I'm accepting this answer anyway. Many thanks for your help. – Cris Luengo May 14 '18 at 05:30