Does FastMM only report memory leaked and/or memory allocated? - delphi

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.

Related

How iOS handles memory corruption from low level C/ Objective-C code?

I have an iOS app that uses some legacy low level memory manipulation code using pointers. I'm debugging an issue where multiple threads are causing multiple copies of these code to be executed on global variables simultaneously and cause memory corruption by writing invalid length or overwriting data.
The effect is that the length of the buffer below may change. I've seen iOS throw EXC_BAD_ACCESS or EXC_BREAKPOINT as a result of these calls.
My question is - would iOS always throw exceptions when I use memcpy incorrectly, or will it complain only when I write outside my allowed memory?
In other words, is my code free to corrupt my memory and create invisible issues, without causing exceptions, as long as it does not step outside allocated memory or access deallocated memory?
NSData* buffer = ...
Byte *array = (Byte*)malloc(buffer.length);
memcpy(array, buffer.bytes, buffer.length);
The last time I checked or had such an issue it would only complain when outside your own allowed memory. In my situation I was writing over whatever objects followed the address I was trying to write to. The result was what seemed a random crash on objects as unrelated as even NSString.
My mistake was something like the following:
MyStructure *myStructure = malloc(sizeof(myStructure)); // Incorrect
MyStructure *myStructure = malloc(sizeof(MyStructure)); // Fixed
A simple autocomplete error which led to days long hunting of this bug. MyStructure was a fairly big one so accessing some property (both read and write) would in this case simply overflow and read/write through whatever was after it. It eventually randomly crash; sometimes bad access, other times just some random exception on a random object.

Does destroy() method deallocate the memory of page?

I am using destroy() method as follows:
onPopTransitionEnded: {
page.destroy();
}
my question is does this destroy() method deallocates all the memmory occupied by the page and its child?
Page{
content:
Container{
ImageView{
//properties
}
}
}
will the destroy() method destroy every thing in content property of page?
The reason behind asking this question is, when I observe the memory using QNX Memory analyzer. I couldn't see the decrease in memory uses. I also observed the memory usage of app in device monitor, as I navigate to next page it shows increment in memory uses but when page is destroyed onPopTransitionEnded the memory uses didn't come down.
Please let me know if there is any tool that may help me to observe the memory uses. or any documentation that may help me.:Helpsmilie:
First of all - yes, "detroy()" will also destroy all implicit and explicit children of your Page, but not instantly:
Note that it is safe to call destroy() on an object within that object. Objects are not destroyed the instant destroy() is called, but are cleaned up sometime between the end of that script block and the next frame (unless you specified a non-zero delay).
You can use Component.onDestroyed() attached signal to ensure that object was deleted.
Seems that memory can be freed little bit later when threshold memory value will be achieved. You can try to test it via creating and deleting a lot of object and obesrving memory usage.

Potential memory leak - Received Memory Warning

I am using iOS 7 and I am getting memory warnings in this part of code, but I'am not able to understand how the retain count increases as I release imageToSave variable too.
Static analyser not always write about memory leak but its assuming that when you are calling finalOutput its returning you an allocated object mean +1 retain count object which is never used and its treating this waring as memory leak!
You have not allocated memory to this object yourself, so you don't own it. And you are still releasing it.You can't release objects you don't own.
Unless you use alloc method to allocate memory, you can't just release them........

Apple Instruments - Reference Counting

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.

Invalid Pointer Operation + Call Stack

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.

Resources