Suppress Valgrind warnings from iOS SDK

Question

I followed this approach to run Valgrind on an iOS app. Unfortunately the warnings pertaining to the iOS SDK make it almost impossible to find any warnings related to my app. Is there a list of iOS suppressions for Valgrind so I don't have to generate them myself?

Answer 1

It looks like you can probably modify the code that's in your main() so that it will pass the proper options to Valgrind. (Note that this assumes that you're running memcheck, which is the default option, and also what you appear to be running from your pastebin).

Valgrind/Memcheck are expected to report errors with the libraries that you already have, including Obj-C/iOS SDK. To suppress Memcheck from reporting errors, use this:

This generates suppressions automatically: --gen-suppressions=yes

---

You can also/might want to go a little bit more in depth and customize what you don't want to see:

Add a suppression file to be considered: --suppressions=/path/to/file.supp.

The suppression-type (second) line should have the form:

Memcheck:suppression_type

The Memcheck suppression types are as follows:

Value1, Value2, Value4, Value8, Value16, meaning an uninitialised-value error when using a value of 1, 2, 4, 8 or 16 bytes.

Cond (or its old name, Value0), meaning use of an uninitialised CPU condition code.

Addr1, Addr2, Addr4, Addr8, Addr16, meaning an invalid address during a memory access of 1, 2, 4, 8 or 16 bytes respectively.

Jump, meaning an jump to an unaddressable location error.

Param, meaning an invalid system call parameter error.

Free, meaning an invalid or mismatching free.

Overlap, meaning a src / dst overlap in memcpy or a similar function.

Leak, meaning a memory leak.

Also check suppressing errors in the Valgrind docs for more info. Note that you are allowed to have multiple suppression files, so I would just write your own that you can always remove later.

---

However, you might want to look at why those errors are appearing. It looks like a lot of them are the SDK, for which you might want to ignore - but possibly after turning on the track origins (which you've done) and checking your own code just in case.

The uninitialized value errors is where you are being warned about uninitialized values (duh) - however, it only does this when you have an uninitialized value that is going to make a difference, since there are other uses of uninitialized values.

Usually, these are allowed to propagate until you use them where you "shouldn't." It reports these values, then, whenever you actually try to use them.

You already know that you can turn on --track-origins=<yes|no> (defaults to no) in order to find out where they are coming from, and it does look like they're from the SDK. For those who don't know, --track-origins is really quite helpful because when it's off, you only know that an uninitialized value is being used in a "dangerous" way, but you will have no idea where the uninitialized value came from.

Remember that Memcheck will reject setting this to yes if --undef-value-errors=no is also being used.