As threatening, when a red spike appears in Leaks, the total memory leak is 1.06 KB, which is highly unlikely to be the source (and not even related) to your problem.
From the point of view of your application, leading to the release of other applications, this is not a problem in itself, and I will be less concerned about this (although to be a good citizen you really should try to minimize this). A more immediate functional problem is why your application is not synchronized and whether this is really the result of a memory warning inside the application itself (or, more precisely, a failure of your application to sufficiently free resources in response to a memory warning, in resulting in subsequent memory allocations for failure).
In my opinion, the first question is whether you really get memory warnings in your application. Typically, I would see something like the following in the console if the application really had a memory warning:
Dec 15 11:12:26 Robs-iPad myapp [2224]: Received memory warning.
But I don't see higher in your console dumps, so I wonder if you really get memory warnings.
I can suggest inserting explicit logging into the application delegate:
- (void)applicationDidReceiveMemoryWarning:(UIApplication *)application { NSLog(@"%s", __FUNCTION__);
or add special processing to the view controller:
- (void)didReceiveMemoryWarning { NSLog(@"%s", __FUNCTION__); [super didReceiveMemoryWarning]; // do whatever you want to free resources here [[[UIAlertView alloc] initWithTitle:nil message:@"didReceiveMemoryWarning" delegate:nil cancelButtonTitle:@"OK" otherButtonTitles:nil] show]; }
This will cause the following to appear on my console:
Dec 15 11:12:26 Robs-iPad myapp [2224]: - [AppDelegate applicationDidReceiveMemoryWarning:]
Dec 15 11:12:26 Robs-iPad myapp [2224]: - [ViewController didReceiveMemoryWarning]
But the main goal is to confirm whether you really get warnings about the memory and whether it really is due to the inability to synchronize your application.
But suppose for a second that the problem is really the result of a memory warning. This leads to two questions: first, what do you do to mitigate memory warnings in the first place (for example, using @autoreleasepool to mitigate high water marks, and not to store a large resource in memory at the same time, if not entirely necessary using imageWithContentsOfFile rather than imageNamed )? Secondly, what do you do in response to warnings about memory (for example, you clear caches, etc.)?
So, if you confirm that the memory warning is indeed the source of the problem (and do it first), then it may be interesting to look at the distribution graph during the synchronization process (and confirm the maximum number of real-time bytes, as well as the final number of active bytes). Looking at the distribution graph in your question, it doesn’t look so bad (i.e., no wild vibrations), but, again, you didn’t share the number of “live bytes” with us, so it's hard to say.
But I definitely will not worry about this 1kb leak when you simulate a memory warning. This is more annoying than any serious symptom you need to worry about. Watch for leaks, but focus on (a) large leaks; and (b) in the code, not in the framework.
My original answer, below, was in response to the original question, which was simply "what is the leak shown by tools that don't seem to match my code." I will save it here for reference:
This may mean that the leak is not in your code, but rather in the system framework (which you hid).
You can share:
call tree with system libraries shown;
information about leaks of objects (so, not only the "call tree", but also a list of "leaks");
some description of what you are doing in the application to reproduce this leak;
which versions of iOS you see that this problem manifests itself, and which versions you don’t have (the frameworks are not without leaks themselves, but it depends on the target iOS); and
what version of Xcode are you using.
Honestly, you can ignore this problem, given (a) the small size of the leak; (b) the absence of an indication that the problem lies in your code; and (c) the fact that the iOS framework is leaking out of your control. But if you are interested, share some of the above data, and we could suggest further observations.