it's my call stack window when i got "Invalid Pointer Operation" Error :
CalStack http://m8spy.com//PersonalFs/M8SPY_Images/CallStack_1.png
What is the reason for this error?
Thank you
You've attempted to release memory that the memory manager doesn't recognize as belonging to it.
The exception comes from an object's destructor, which indicates that you're attempting to free an object that has already been freed. Otherwise, you're calling Free on an variable that never had a valid object reference in the first place; heed compiler warnings about uninitialized variables.
Please, see item "FastMM" in this article. Though it says about memory leaks, it is really an introduction to debugging memory managers, which are used to find problems with dynamic memory - just like your case.
Related
In my application, I have a series of long running processes. Sometimes, when the app gets backgrounded, one of these processes will return and try to notify other objects (which have been released) that it has completed, causing an EXC_BAD_ACCESS. Something like:
[process runForALongTimeWithCompletion:^(){
[possiblyReleasedObject heyTheProcessFinished];
}];
How can I check if possiblyReleasedObject has been released? Or, more precisely in my case, how do I check if it is dereference-able, such that referring to it won't cause a EXC_BAD_ACCESS error?
There is no way to (safely) check if a pointer to an object points to a valid memory location in Objective-C. You'll need to structure your program such that objects holding a pointer to possiblyReleasedObject retain it so that it doesn't get inadvertently released.
When an object holding a pointer to possiblyReleasedObject no longer needs it, it's generally good practice to set the pointer to nil after calling release in order to avoid accidentally dereferencing a bad pointer.
I'm having trouble understanding what's happening here. I am debugging an app because I think it's retaining a class 'DownloadController' after its been used. Using ARC, it should automatically release the object when the Reference Count is zero.
So in instruments it looks like
From that I assume, that 48 bytes have are still 'live' and being used, correct?
So I try to find what is causing this object to be retained, when its no longer needed, by using reference count traces.
At the bottom it says, RefCt is zero; so why has the object not been released? How can I debug further, why it hasn't been released?
These ARC anomilies were being caused by NSZombieEnabled, after removing this argument it started freeing objects.
I encountered this thing in a book which I am reading and it got me thinking:
"When you allocate a block, it is created on the stack. This means that, even if you were to keep a strong reference to it, calling it later would result in a crash because the memory would be destroyed as soon as you leave the method in which it was defined."
I thought if I have a strong pointer to something, it is kept alive?
Does this mean this does not apply for objects allocated on the stack?
I am trying to think of an example without using blocks...(e.g., of pointer - maybe an ivar- pointing to a stack allocated object which gets destroyed even though the pointer is alive)
Objects are never allocated on the stack in Objective-C. Blocks are special however, since they are stack allocated. So if you want to retain a pointer to a block, you must first copy it by using Block_copy and use the copy, then release it with Block_release. This must be done if the block is to be used after the scope it was declared in is destroyed. More on the matter here: https://developer.apple.com/library/mac/documentation/cocoa/Conceptual/Blocks/Articles/bxUsing.html (under "Copying Blocks"). Yet again though, this does not apply to regular objects.
Blocks can be messaged like objects. To move them from the stack to the heap, just "copy" them.
void (^stackBlock)() = [^(){
NSLog(#"Hello world");
} copy];
My code is:
SCDownloadManagerView *downLoadMnger = [[SCDownloadManagerView alloc]init]
[self.vw_ownVw addSubview:downLoadMnger.view]
[self.vw_ownVw bringSubviewToFront:downLoadMnger.view]
I am getting this error on second line [self.vw_ownVw addSubview:downLoadMnger.view]
Please help me.
In my experience, what usually causes this error is when memory has been released prematurely. In this case, it is possible that your program is trying to use an array, but because it was not properly retained, the array was deallocated, and an NSString was allocated in the same spot. When your program tries to access the array, it sends the count message to where it thinks the array is, but because a string has been allocated there instead, the string gets the count message and this causes an error because strings don't respond to count.
The code you posted is not the cause of the problem, it is only the point at which this bug is manifesting. In order to find the cause, you need to review your memory management. Try running "Build & Analyze", the static analyser is very good at picking up obvious mistakes in memory management. Review parts of your code that deal with arrays, but keep in mind that the array in question could also be managed by another object outside of your code (such as a view or view controller) that you have released too early, etc.
I am debugging my program with FastMM and it seems that a lot of the memory leaks it is reporting seem legitimate memory allocation not an actually memory leak.
For instance,
A memory block has been leaked. The size is: 20
This block was allocated by thread 0xD44, and the stack trace (return addresses) at the time was:
404902 [System.pas][System][#GetMem][3693]
406597 [System.pas][System][TObject.NewInstance][11044]
406B2A [System.pas][System][#ClassCreate][12121]
60A1D2 [CtrlObjs.pas][Ctrlobjs][TConnObj.Create][430]
61703B [Control.pas][Control][TControlMgr.FindLinks][854]
60ACB2 [CtrlObjs.pas][Ctrlobjs][TControlObject.FindLink][746]
60E2A3 [CtrlObjs.pas][Ctrlobjs][TDelayControl.EvalPulse][2105]
60E4C0 [CtrlObjs.pas][Ctrlobjs][TDelayControl.Evaluate][2193]
6102D4 [CtrlObjs.pas][Ctrlobjs][TLineControl.Evaluate][3155]
60ABF1 [CtrlObjs.pas][Ctrlobjs][TControlObject.ActiveCount][711]
6105D8 [CtrlObjs.pas][Ctrlobjs][TLineControl.ActiveCount][3261]
The block is currently used for an object of class: TConnObj
TConnObj is class that is frequently used to create an object and be destroyed when the program is not need it anymore. However, FastMM is reporting it to be actual memory leak. So, how do you tell which is which when looking at the FastMM memory leak log file?
If FastMM is reporting it as a leak then it really is a leak.
You have created an object and failed to destroy it before the program terminates. Usually this is due to a straightforward error in your code. Perhaps you omitted a try/finally to protect the object's life.
If it's a global scope object that is not being destroyed then you could simply destroy it at program termination. Or you could call RegisterExpectedMemoryLeak to indicate that you do not intend to destroy that object. But only do that when you intentionally leak an object. Don't use it to paper over a leak that is not intentional.
But the bottom line is that FastMM does not lie. If it says you are leaking, trust it.