12

Is it possible to tell valgrind to ignore some set of libraries? Specifically glibc libraries..

Actual Problem: I have some code that runs fine in normal execution. No leaks etc.

When I try to run it through valgrind, I get core dumps and program restarts/stops.

Core usually points to glibc functions (usually fseek, mutex etc). I understand that there might be some issue with incompatible glibc / valgrind version.

I tried various valgrind releases and glibc versions but no luck. Any suggestions?

Andy Lester
  • 91,102
  • 13
  • 100
  • 152
Jack
  • 1,398
  • 3
  • 16
  • 26

4 Answers4

11

This probably doesn't answer your question, but will provide you the specifics of how to suppress certain errors (which others have alluded to but have not described in detail):

First, run valgrind as follows:

 valgrind --gen-suppressions=all --log-file=valgrind.out ./a.out

Now the output file valgrind.out will contain some automatically-generated suppression blocks like the following:

{
   stupid sendmsg bug: http://sourceware.org/bugzilla/show_bug.cgi?id=14687
   Memcheck:Param
   sendmsg(mmsg[0].msg_hdr)
   fun:sendmmsg
   obj:/usr/lib/libresolv-2.17.so
   fun:__libc_res_nquery
   obj:/usr/lib/libresolv-2.17.so
   fun:__libc_res_nsearch
   fun:_nss_dns_gethostbyname4_r
   fun:gaih_inet
   fun:getaddrinfo
   fun:get_socket_fd
   fun:main
}

Where "stupid sendmsg bug" and the link are the name that I added to refer to this block. Now, save that block to sendmsg.supp and tell valgrind about that file on the next run:

valgrind --log-file=valgrind --suppressions=sendmsg.supp ./a.out

And valgrind will graciously ignore that stupid upstream bug.

  • 1
    somewhat related... https://stackoverflow.com/a/14779512/52074. the link talks about how to create your own wildcard suppression rules. – Trevor Boyd Smith Apr 13 '18 at 15:42
4

As noted by unwind, valgrind has an elaborate mechanism for controlling which procedures are instrumented and how. But both valgrind and glibc are complicated beasts, and you really, really, really don't want to do this. The easy way to get a glibc and valgrind that are mutually compatible is to get both from the Linux distro of your choice. Things should "just work", and if they don't, you have somebody to complain to.

Norman Ramsey
  • 198,648
  • 61
  • 360
  • 533
3

Yes, look into Valgrind's suppression system.

unwind
  • 391,730
  • 64
  • 469
  • 606
  • I think he wants to tell valgrind not to profile certain glibc functions, not just suppress the resulting output. – Tim Post May 24 '10 at 14:50
  • @Tim: Exactly! Basically I want valgrind to ignore them (execute them just like normal execution) – Jack May 24 '10 at 16:27
  • @Jack - you'll need to get rather familiar with valgrind internals for that. I really suggest taking a peek at valgrind/valgrind.h , its hard to suggest something unless you post the output you received from valgrind. – Tim Post May 24 '10 at 17:21
1

You probably want to ask about this on the Valgrind user's mailing list (which is extremely helpful). You can suppress output from certain calls, however, suppressing the noise is all you are doing. The calls are still going through Valgrind.

To accomplish what you need, you (ideally) match Valgrind appropriately with glibc or use the macros in valgrind/valgrind.h to work around them. Using those, yes, you can tell valgrind not to touch certain things. I'm not sure what calls are borking everything, however you can also (selectively) not run bits of code in your own program if its run under valgrind. See the RUNNING_ON_VALGRIND macro in valgrind/valgrind.h.

The other thing that comes to mind is to make sure that Valgrind was compiled correctly to deal with threads. Keep in mind that atomic operations under Valgrind could cause your program to crash during racey operations, where it otherwise might not, if not properly configured.

If you have been swapping versions of valgrind and glibc, there's a chance you found a match, but incorrectly configured valgrind at build time.

Tim Post
  • 33,371
  • 15
  • 110
  • 174