Why does instruments using the leaks tool show so many leaks and then crash after about three leak detection cycles?
That cannot be normal ?
The app I am testing on has one index window with one label in it which, on click opens another window which on click closes itself again.
No big deal yet it seems to have leaks ?
the first detection says 72 new leaks
the second then 8 new leaks ... ?
Does anyone know why this might be ?
Thanks for your help trying to get my head around this
Having developed apps with Titanium for 8 years now this doesn't look anything like it should. Whenever leaks are found by the community it usually is quickly fixed by the dev team. That said, it is very rare leaks are found.
Most memmory leaks are developer generated. For example if you create references to UI elements outside the controller it is in you will have to clean up the reference to that UI element to let garbage collection handle it. Garbage collection cannot trigger if you didn't free the components up.
I will not be able to help you further besides the above as you have not provided any relevant information like SDK version, code that causes it etc. You might've stumbled upon a real memory leak but chances are you're not freeing up resources.
Wondering if others have experienced this as well in Xcode: my app seems to have no crash issues when running normally OR in Instruments (Allocations) but if I run it from the debugger on my phone it will eventually (after ~10 rounds in my game) crash due to memory error (no other information provided).
One thought: I have malloc stack logging enabled and was curious if this might lead to memory accumulation that is unrealistic otherwise. At this point it seems like there's no real-world / non-debugger issue based on my testing, but as a relative rookie at memory management I am uncomfortable saying Xcode is giving me a false positive. Any ideas?
I am new to Xcode and the profiling tool, instruments. I tried to find leaks of my c program. Everything is fine. It shows no leaks, but I don’t understand some terms used in the program. Does mean I still have memory leaks somewhere else in the program?
Applications like the debugger and Instruments may hook into your program after the OS has already started it running. What the message is saying is that it doesn't know how a given piece of memory was allocated because it was allocated before Instruments hooked into your program. So it has no way to track where it came from. It may or may not mean that there are more actual leaks in your program.
I believe that you can start your program from Instruments in most cases, which I think would eliminate the issue. Once you've run it once, you should be able to press the Record button (the red circle) again and it should run the app once more. I think in that situation, it should have access to all of the allocations your app makes.
For what it's worth, I have seen this message before and had it go away during the same run. It was as if it suddenly found the data that explained where the leak came from. I've also seen it happen on one run and be gone on a subsequent run with the same data. In that case it seemed like a timing issue of Instruments and not a legitimate leak.
1.X-Code -> Run -> Run with Performance Tool -> Leaks i am getting a memory leak like Responsible Library :UIKit Responsible Frame:UIKeyBoardInputManagerClassForIn.When i traced it does not point to my code instead it points to some frame works.Is this issue of my code? or any chance of leak from apple's frame work?
In X-Code 3.2 I connected iPhone device and the clicked Build & Analyze the right clicked on product/press cmnd+shift+(A/B) you can see many potential leaks this is static analysis but it is showing potential leaks caused only by my code.Hope this would be helpful for some one.
This issue related to the frameworks.Not in your code.So it can't so in your code.So asper my knowledge no need to worry.
I'm trying to use boundschecker to analyze a rather complex program. Running the program with boundschecker is almost too slow for it to be of any use since it takes me almost a day to run the program to the point in the code where I suspect the issue exists. Can anyone give me some ideas for how to inspect only certain parts of my software using boundschecker (DevPartner) in Visual Studio 2005?
Thanks in advance for all your help!
I last used BoundsChecker a few years ago, and had the same problems. With large projects, it makes everything run so slowly that it is useless. We ended up ditching it.
But, we still needed some of it's functionality, but like you, not for the whole program. So we had to do it ourselves.
In our case, we mainly used it to try and track down memory leaks. If that's your objective as well, there are other options.
Visual Studio does a pretty good job of telling you about memory leaks when your program exits
It reports leaks in the order that they were created
It will tell you exactly where the leaked memory was created if your source files have this at the top
#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif
Those help a lot, but it's often not enough. Adding that snippet everywhere isn't always feasible. If you use factory classes, knowing where memory was allocated doesn't help at all. So when all else fails, we take advantage of #2.
Add something like the following:
#define LEAK(str) {char *s = (char*)malloc(100); strcpy(s, str);}
Then, pepper your code with "LEAK("leak1");" or whatever. Run the program, and exit it. Your new leaked strings will display in Visual Studio's leak dump surrounding the existing leaks. Keep adding/moving your LEAK statements and re-running the program to narrow your search until you've pinpointed the exact location. Then fix the leak, remove your debugging leaks, and you're all set!
BoundsChecker tracks all memory allocations and releases in extreme detail. It knows, for instance, that such and such a memory allocation was done from the C runtime heap, which in turn was taken from a Win32 heap, which in turn started life as memory allocated by VirtualAlloc. If the application was instrumented (FinalCheck), it also has detailed information as to which pointers reference the memory.
This is one reason (of many) why the thing is slow.
If BC were to connect to an application late, it would have none of this data built up, and would have either (1) dig it all up at once, or (2) start guessing about things. Neither solution is very practical.
One way to lighten up BoundsChecker is by excluding from instrumentation all but the few modules you are interested in. I know thats not great because if you knew where the leak was you wouldn't need BoundsChecker. What I usually recommend is that you use BC's Active Check mode first with only Memory Tracking available. You miss the API Validations but you could always rerun that seperately. After you run Active Check and you get clues regarding which modules tend to be problematic, only then do you enable instrumentation for the module or modules of interest and their dependencies. We know Final Check is annoyingly slow but as Mistiano correctly states, with Final Check not only does BC keep a graph of all allocated blocks but also all pointers and contexts to them. Therein lies the magic in how Final Check can nail leaks and corruptions at the point of occurance, not just on application shutdown or fault. Shameless plug: I work on the DevPartner team. We are releasing DPS 10.5 on February 4, 2011 with x64 application support in BC. Unlike the relatively ancient and undersold BC64 for Itanium which only provided Active Check, DPS 10.5 provides full Final Check support for x64 applications, both for pure C++ and for native modules running in .NET processes. See microfocus.com under MF Developer for details.