I am using XCode 4.3.1 and something strange is happening when I debug my app in last few days.
Here is the code:
-(void) init
{
list = [[NSMutableArray alloc]init]; // list is declared in the header
}
-(void) dosomething
{
[self init];
// strangely the debugger shows "list" is still null here
[list addObject: something];
// but it happily steps over the above line without adding anything to the list
}
Another problem (somewhere else in the code) is that sometimes the debugger decides to jump several lines (as if it switches over to another thread but there's only one thread)
The worst part is sometimes when I step over the code it even goes backward a few lines and and then forward again.
I tried to switch to GDB but to no avail. Has anyone run into these problems?
Btw, i was doing some profiling to find memory leaks before these things start happening
The problem is that you are running your project with compiling optimizations, probably because you debug it in release mode ; or because for some reasons you have some compiling optimizations defined in your project settings in debug mode. Check if you have the message hereafter in your XCode console :
[Project Name] was compiled with optimization - stepping may behave oddly; variables may not be available.
If yes, read this : 'Project Name' was compiled with optimization - stepping may behave oddly; variables may not be available
Related
I've encountered a very annoying problem that has cost a lot of time for several months now.
I have a project in MPLAB X. When I use a line-breakpoint it does not break on the right line at all when debugging my project.
I am using MPLAB X v4.15
This is what actually happens:
No matter where the breakpoint is, the debugger never breaks at the right place.
if I put a breakpoint somewhere, it always breaks at the wrong position
if I then restart the debugging it breaks at the same wrong position
If I change the breakpoint location, the position where the program actually breaks is different, but stays the same again when i restart the program.
Some more info:
Why does this happen?
Are there more people with this problem?
How do i solve this?
EDIT
Sadly, the solution suggested by K_Trenholm did not work for me. I put 3 "NOPs" in one function, but it didn't work as you suggested. See the picture below:
but what I got:
I would like to add that I tried various combinations of breakpoints for the NOPs. No matter what i do, the program always halts at the same PC for this case, seen in the picture above.
Thank you for your reply, it is very helpfull to even have ANY ideas on how to solve it.
If you have any other ideas, I would be very grateful if you would share them!
Two things come to mind:
1) Compiler optimizations can cause problems with breakpoint locations/values when debugging. When debugging, turn optimizations off (if possible, it looks like in your example you're bumping up on the ceiling in terms of code size).
2) Breakpoint "Skidding". See http://microchipdeveloper.com/tls0201:skid-effect#top-of-page
One way to work around this from what I've seen is to put a couple NOP instructions after the line where you plan on placing the breakpoint. This will ensure that any "skidding" will not execute more code.
The instruction where the break occurs will always execute completely, and anything pending in the pipeline will execute as well. For single cycle instructions, this adds a one instruction skid. For multiple cycle instructions and branches, it adds multiple cycles. So if you want to avoid
to jump the debugger into a subroutine you had to include some Nop behind the breakpoint.
example:
void main (void)
{
int x = 0;
x++1; //put Breakpoint here
Nop();
Nop();
Nop(); //Debugger will stop here
foo(x); //so foo() is not called
}
Depending on the MCU being used the debugger will introduce a 'skid effect' upon hitting a breakpoint. The debug session will execute up to two extra instructions before halting.
My app crashes on devices with 0.5GB memory. However, profiling memory usage in Xcode - it rarely goes above 140MB. I've used instruments to check leaks and there are none that are significant.
However, when I run my app, the memory used by 'Other Processes' is always very high. This is the resting state after launching:
I added a 1 second delay in each cycle of a loop in my code, and discovered that on each loop, the 'other processes' increases memory usage by about 3MB per object, until on 0.5GB devices, it runs out and crashes.
This question suggests that these are other apps using that memory, but I have closed every other app and the usage directly correlates with my looping code.
What could be using memory in other processes, that is actually running in my app? And why is my 'Other Processes' using up so much memory?
To give an idea of what I'm doing, I'm pulling data from Parse, then looping through each of the objects returned and creating an SKNode subclass object from the data. I add this node to an array, (for reference) and to the scene. Here's the code I'm doing on the main thread with the delay added. NB the line:
self drawRelationships:[_batches objectAtIndex:_index] forMini:_playerMini];
Is a BFTask and so asynchronous. And I'm dividing the array into smaller batches so I can see incremental memory usage, as each batch is drawn. If I try to draw the whole lot at once, OOM occurs immediately...
- (void)drawNewRelationships
{
_batches = [NSMutableArray array];
_index = 0;
[_playerMini fetchInBackgroundWithBlock:^(PFObject *object, NSError *error) {
[ParseQuery getNewRelationshipsForMini:_playerMini current:_miniRows.relationshipIds withBlock:^(NSMutableArray *newRelationships) {
_batches = [self batchArrays:3 fromArray:newRelationships];
_index = 0;
[self drawBatches];
}];
}];
}
- (void)drawBatches
{
if ([_batches objectAtIndex:_index]) {
[self drawRelationships:[_batches objectAtIndex:_index] forMini:_playerMini];
_index++;
if (_index < [_batches count]) {
[self performSelector:#selector(drawBatches) withObject:nil afterDelay:1];
}
}
}
The node contains other data, (a couple of arrays, custom object) and I've tried running the app with all that data removed. I've tried running on the main thread and background threads. I've tried using BFTask to do things asynchronously. Everything I've tried ends up with the same behaviour - creating these SKNode objects eats up memory in 'Other Processes', until on low memory devices, it crashes.
It might be worth noting, that this behaviour has only started to occur since iOS9.
Basically, what can be using all this memory in 'other processes' and how can I free it?
Update
I've tried running the Sprite Kit sample app, and even that uses ~550MB in other processes when it launches. Could this be a major Sprite Kit bug?
Well it turned out to be a rather specific issue. The memory allocated to other processes was in fact memory leaking from my app. It occurred when I flattened a node with many children, but didn't nil an NSDictionary that contained references to all the pre-flattened nodes. For some reason, this mem leak didn't show up when profiling.
I also found a very good blog post: http://battleofbrothers.com/sirryan/memory-usage-in-sprite-kit on reducing your app's memory footprint. Worth a read if you're trying to optimise.
I want to provide a solution for those who are not necessarily using SpriteKit, but are facing issues with Other Processes taking up more and more memory - meaning there is a leak. This is the best way I've found to debug leaks in 'Other processes' so far.
Open Instruments, select Activity Monitor
Reproduce the steps in your application, see which process is taking ownership for the leak. For example if it is mediaserverd, you probably have a leak revolving around encoding/decoding or something media related, so things like releasing buffers or releasing the decompression session might not be working as planned.
Now that you have an idea of where to look, open Xcode and use the Debug Memory Graph tool, and look for the potential leaking instances, and you should see all the strong references towards it. For myself working a lot in objective-c++ it turns out to be missing autoreleasepools quite often.
I have a bug which I have uncovered by enabling Scribble in Xcode, fixing the bug is not an issue, it isn't implemented in the best way, I can just remove the whole block, but I don't understand why I am getting the issue in the first place, which tells me I don't understand something
If I have Scribble enabled, when it tries to execute the release line in the code below it crashes without fail,
HDClipPlaybackController * theController = nil;
if( theSource != nil ) {
theController = [[HDClipPlaybackController alloc] initWithClipProxyList:theSource];
}
else {
theController = [[HDClipPlaybackController alloc] initWithClips:clips handles:[handles intValue]];
}
theController.startIndex = [startIndex intValue];
theController.completionHandler = ^(BOOL success){
theController.completionHandler = nil;
[theController release]; // <-- CRASH
};
[theController performSelectorInBackground:#selector(startDownloadingClips:) withObject:theController.clipProxyList.everyClipProxy];
Thread 1: EXC_BAD_ACCESS (code=1, address=0x55555555)
adding a break point on the line before the release line and looking at the value of theController it is a valid object addres but stepping onto the next line I can see the value has changed to 0x55555555 (Scribble has freed it), which I would take to mean that the memory for the block has been freed, since my understanding is that the local variable is copied into the blocks scope, but that would mean the blocks memory is being freed before it has finished executing? If I just move the release to outside the block, the crash goes away, also if I enable Zombies instead of Scribble I don't have any issue, so it doesn't look like an over release issue to me. The variable theController isn't declared __block, so it should just be a simpler pointer inside the block scope if I understand things correctly.
This is a Mac OS X app running as 32bit, with Xcode 6.1.1 and Mac OS 10.9.5.
On the theController.completionHandler = nil; line you remove the last reference to the block, which causes the block to be deallocated. Then on the [theController release]; line, you access the block's captured copy of the theController variable, which is stored in the block. But you already deallocated the block, so you are accessing a field on a deallocated thing.
I am stuck with the Cocoa Memory Managagment.
- (IBAction) createPush:(UIButton *)sender {
[create setEnabled:NO];
[release setEnabled:YES];
aLocation = [[Location alloc] init];
// Put some Example Stuff in the Class
aLocation.title = #"Apartment";
aLocation.street = #"Examplestreet 23";
aLocation.zip = #"12345";
aLocation.city = #"Exampletown";
aLocation.http = #"http://google.com";
aLocation.info = #"First Info Text";
aLocation.info2 = #"Second Info Text, not short as the first one";
aLocation.logoPath = #"http://google.de/nopic.jpg";
[aLocation.pictures addObject:#"http://google.de/nopic.jpg"];
[aLocation.pictures addObject:#"http://google.de/nopic.jpg"];
}
- (IBAction) releasePush:(UIButton *)sender {
[release setEnabled:NO];
[create setEnabled:YES];
[aLocation release];
aLocation = nil;
}
This Code works fine if I set or get Variables, but when I call the 'last' release (so the retain count is 0) it dealloc Method of aLocation gets called, but in Instruments Allocations you see that no memory is given back.
Here the Sources of Location:
http://homes.dnsalias.com/sof/Location.m
same Link with a '.h' instead of '.m' for the Header file (sorry its because of the Spaming Rule).
And the whole Project: http://homes.dnsalias.com/sof/Location.zip
Thanks for any help, where is my failure? Dennis
This Code works fine if I set or get
Variables, but when I call the 'last'
release (so the retain count is 0) it
dealloc Method of aLocation gets
called, but in Instruments Allocations
you see that no memory is given back.
What do you mean by "no memory is given back"?
Though oddly named, the memory management of aLocation is correct is the above code (assuming you have released it in dealloc as well).
Why doesn't memory use decrease when a single object is released?
(Paraphrased)
It is likely that your object is relatively tiny and, thus, that single deallocation falls below the ~20K or so needed to show up in Instruments.
If your app is crashing due to memory use issues, looking to a single deallocation is the wrong place to start. The first thing to do is to answer why your app is accreting memory and what is responsible for that growth.
Configure the Allocations instrument to only track live allocations. Then sort by total memory use. That'll show you what type of allocation is consuming the most memory. Start by reducing that.
Heapshot analysis can be very effective in these situations.
Additional Infos here because of maximum number of links and I have'nt the opportunity to post images...
What do you mean by "no memory is given back"?
I will show you the Instruments run, then it should be clear.
Screenshots from Instruments run
If want more Detail klick here for Instruments Run.
Your code is just fine. You are mistaken the output from Instruments. There is no Location object leaking.
For leaks, use the "Leaks" instrument. It won't fire. :-)
I'm getting peppered with
*** __NSAutoreleaseNoPool(): Object 0x1961180 of class NSEvent autoreleased with no pool in place - just leaking
warnings during run-time and have no idea what the cause is. Cursory Googles indicate that this is a symbol I can break on with Xcode, but adding it as a symbolic breakpoint via Run>Manage Breakpoints>Add Symbolic Breakpoint, or simply via the breakpoints management window, results in a breakpoint with a - next to it instead of a check, which I take to mean it's a symbol that can't be found.
I've tried adding the symbol "__NSAutoreleaseNoPool" with two underscores, one underscore, and now I'm just feeling stupid. The errors continue to get logged and no breakpoints get hit. Any pointers for breaking on Obj-C symbols or debugging this would be appreciated.
[EDIT: after maybe 10 (10 more, so a couple dozen total, including at least two Xcode restarts) runs I got "Pending breakpoint 9 - "__NSAutoreleaseNoPool" resolved" printed to my console and the breakpoint started working. Is there any way to force a pending breakpoint to actually resolve?]
To actually answer your question, look in NSDebug.h. There you will find a comment of which this is part:
NAME OF ENV. VARIABLE DEFAULT SET TO...
NSDebugEnabled NO "YES"
NSZombieEnabled NO "YES"
NSDeallocateZombies NO "YES"
NSHangOnUncaughtException NO "YES"
and farther down are these comments:
// Functions used as interesting breakpoints in a debugger
// void __NSAutoreleaseNoPool(void *object);
// Called to log the "Object X of class Y autoreleased with no
// pool in place - just leaking" message. If an environment
// variable named "NSAutoreleaseHaltOnNoPool" is set with string
// value "YES", the function will automatically break in the
// debugger (or terminate the process).
// void __NSAutoreleaseFreedObject(void *freedObject);
// Called when a previously freed object would be released
// by an autorelease pool. If an environment variable named
// "NSAutoreleaseHaltOnFreedObject" is set with string value
// "YES", the function will automatically break in the debugger
// (or terminate the process).
So you don't really need to set these breakpoints; just set the appropriate environment variables. You can do the latter either from your e.g. .bashrc or in Xcode 4 you can edit the "Run" section of your "scheme" and set them there -- that's what I do, and it works just fine.
I have the same issue on setting breakpoint on __NSAutoreleaseNoPool().
I finally successfully set the break point use gdb command.
After debugger started, press ctrl+C in debugger console.
Use "br __NSAutoreleaseNoPool" to set the break point and restart the debugger.
It sounds like you're using Cocoa in a thread somewhere and not wrapping the thread body with an autorelease pool. You probably don't need to use breakpoints to find this. Are you doing any detachNewThreadSelector?
The issue here is simple: You are releasing with no pool in place. This usually happens in command line tools written against Foundation. Simply add the following code to your main(): (Irrelevant parts omitted)
int main (…) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
/// Your code goes here.
[pool drain]; // This one might not strictly speaking be neccessary.
[pool release];
return 0;
}
Edit: If you are not creating a command line tool, chances are you are doing something naughty; but nonetheless: If you have code you invoke before NSApplicationMain(), you need to wrap this in the same basic code, draining and releasing the pool before the invocation of NSApplicationMain.
I know this is an old thread. Just wanted to share some light on the right solution.
The right way to have a breakpoint at _autoreleasenopool is using the breakpoint navigator in xcode.(use the key command+6).
In the bottom left portion of the breakpoint navigator click '+' sign and add symbolic breaakpoint. Enter the symbol as objc_autoreleaseNoPool.