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?
Asked
Active
Viewed 740 times
21
-
2+1, Learnt something new today – TeaCupApp Jul 03 '12 at 03:23
-
Any warning(s) specifically in the main.m you'd like to suppress? – CodaFi Jul 03 '12 at 03:41
-
@CodaFi I'm getting a whole bunch of "Conditional jump or move depends on uninitialised value"'s that if I'm not mistaken all seem to come from the SDK. See http://pastebin.com/fVHnhNh6 for an extract. – moinudin Jul 03 '12 at 03:54
-
[This](http://stackoverflow.com/questions/2612447/pinpointing-conditional-jump-or-move-depends-on-uninitialized-values-valgrin) might be of some use then. – CodaFi Jul 03 '12 at 03:57
-
I'm already using `--track-origin` (not in that extract though, this one does: http://pastebin.com/EiaT3FGF). All the cases I've sifted through have lead to origins in the SDK. My app's name is Geomon fyi when going through those pastes. – moinudin Jul 03 '12 at 04:00
-
1[I know your work](http://itunes.apple.com/us/app/geomon/id390880114?mt=8) ;). Anyways, would a `#pragma clang diagnostic push/pop` fix any of them? – CodaFi Jul 03 '12 at 04:13
1 Answers
3
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_typeThe 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.
