Whenever I am using ASIHTTPRequest for making webservice calls I am randomly getting the following crash:
autorelease pool page 0x9418000 corrupted
magic a1a1a100 4f545541 454c4552 21455341
pthread 0xb0103000
My code is ARC-fied and used -fno-objc-arc for the .m files of ASIHTTP class.
Does anybody have an idea about this or did anybody face this kind of issue before? Thanks in advance!
This likely indicates that you're stomping memory somewhere else. I'd start by turning on memory diagnostics and looking for mistakes. The most likely place to cause these kinds of mistakes is in C code, particularly when using C arrays or C strings. You're probably writing outside of your allocated memory, or writing into memory after you freed it.
There have at times been compiler bugs that would cause this kind of problem, but these are very rare, and I would strongly suspect your code first.
As Rob pointed out, this is likely an indication that you're misusing memory elsewhere. To turn on memory management diagnostics as of Xcode 8:
Click the scheme menu in Xcode and choose "Edit Scheme..." at the bottom.
In the Run step, go to the Diagnostics tab.
Under Memory Management, turn on all four options. I generally find Guard Malloc to uncover the most problems but they can all be useful.
Related
I have found few memory leaks when I am running my application. For your reference, I am sharing the screenshots of Instrument debug logs and also Xcode Debugg memory graph tool. I am not getting what is going wrong here. Please help me to resolve memory leaks.
Please help me to fix the memory shows in the image. Thank you.
I know this is an old question, but a few observations.
When you have a lot of objects that are leaking, focus on high level objects (especially your own classes). We do not care why the array was not released. We care about why the item that is keeping a strong reference to it was not released. XTubeManager and GlueTubeManager are probably good places to start searching, but I don't know what other high level objects appear in the panel on the left.
When you have leaks, it is very useful to use the “Malloc Stack Logging” feature. So edit your scheme (command+<; or “Product” » “Scheme” » “Edit”) and go to the “Diagnostics” section and temporarily turn on “Malloc Stack Logging”:
Then, when you select a leaked object, you can see where it was instantiated but using the memory inspector panel on the right:
Look for entries in that stack trace that are white (your code), as opposed to all the system items that are in gray. When you hover items in that stack trace, there is even a little arrow that lets you jump to the code in question. In my example, the leaked object was instantiated in viewDidLoad.
This will not tell you why it leaked, but you will be able to see where the object in question was instantiated in your code, and you can start your investigation from there, diagnosing why an object created at that point in your code still has lingering strong references.
Remember to turn off the “Malloc Stack Logging” feature when you are done with your diagnostics.
As an aside, when we see URLSession objects that were not released, that begs the question of whether you instantiated a URLSession object (rather than using the shared instance) and neglected to call finishTasksAndInvalidate. Ideally, you would have a single URLSession and reuse it for all network activity (or use the shared instance), but if you must instantiate sessions, make sure to invalidate them when you are done.
You do NOT need to use Instruments. That's the old way. Use Xcode itself.
See Visual Debugging with Xcode
- 24:45
Watching the video is a MUST, but the summary of the video is as such:
There are two type of memory problems. You just have to repeat a flow in your app 2-3 times to be certain the memory graph has caught it
Leaks. Xcode will annotate this with purple icon. Possible are: delegates, closures
Abandoned memory. Xcode will not annotate this. But it's still increases your memory footprint. possible examples are: A repeating timer that is never invalidated, NotificationCenter, A never ending DispatchWorkItem
For Leaks the memory graph is a loop ie two way.
For Abandoned memory the graph is NOT two way. It's just an object one that Apple categorizes as 'root path' referencing your object and never letting it go. For more on this see here
In this case, just because some tool says you’ve got a memory leak doesn’t mean you have one. The amount of data seems to be less than 1MB, that’s nothing. Your tool suspects there’s a leak because data was allocated and not released, but these are single objects. Quite possible that memory is going to be released or reused later.
Use your software for hours and check if memory usage gets larger.
Memory on mobile devices is a shared resource. Apps that manage it improperly run out of memory, crash, and suffer from drastically decreased performance.
so to fix it follow this steps
Open Xcode and build for profiling.
Launch Instruments.
Use the app, trying to reproduce as many scenarios and behaviors as possible.
Watch for leaks/memory spikes.
Hunt down the source of the memory leaks.
Fix the problem.
I am developing an app for the iPhone and am encountering some memory management issues. During execution of the app the live bytes continuously increase without bound. I have tried to track down the issue within my code but cannot seem to find anything that would cause the live bytes to increase so dramatically. The one thing that I have noticed during execution is that the allocation for CFString(Immutable) increase the most rapidly and never decrease or stay constant. Does anyone have any idea why this may be happening? All that the app is doing during this execution is populating a table view from a local array or strings, then downloading another array of string objects and populating a different table view. I am using ARC.
Given the lack of anything concrete to go on, I'll give you somewhat general counsel:
See Finding leaks with Instruments for guidance on how to use Instruments to find leaks.
For specific advice how to go from you allocations, to a more meaningful analysis of the source of those allocations, see point #4 of this Stack Overflow answer. In short, highlight one of your unexplained jumps in allocations, set the bottom window to show you the call tree, hide system libraries, and see in which of your routines the memory is being consumed.
Also, don't overlook the static analyzer, which is especially important if you don't use ARC, or if you use any Core Foundation calls.
Are you doing anything with Core Foundation functions? If so, you obviously need to know that you either have to explicitly transfer ownership to ARC (with either CFBridgingRelease or __bridge_transfer) or manually call CFRelease. The static analyzer of my prior point would point this out to you, though.
It's a weird situation for me that I cannot run my project on device or emulator but when I choose profile instead of run option, the app run flawlessly without any zombie guys.
It happens after I convert my project to ARC. I just modify code as Xcode tell me todo and due to the size of this project, I cannot look through every line of code.
ps. I'm the third hand on this application, so it's almost impossible for me to understand 10k lines of code.
Have you tried enabling Zombies in Xcode itself without profiling? This will set objects to never dealloc so that when you message an object that has a zero retain count, it will know what the object is and tell you. Just make sure you turn it on again so that objects will dealloc as normal.
See how to do that here:
How to enable NSZombie in Xcode?
the following can help you after the fact, but it's best IMO to perform them before migration; if a problem exists, ARC will solve some issues while abstracting others from you:
1) Create more Autorelease Pools one approach which might help you narrow things down is to explicitly create autorelease pools -- this can help localize some of your app's memory related issues. explicitly adding autorelease pools has other benefits, so this can be done not only for bug-seeking.
2) Use GuardMalloc as well, there are other memory related tools -- your app should also run fine with GuardMalloc enabled. switching to ARC could change the point of destruction -- you may be holding on to a dangling pointer.
3) Remove all Leaks finally, this may sound backwards -- remove all leaks possible. you want memory operations and lifetimes well defined. if you have an occasional leak, your issue could be hard to detect. oftentimes, reducing leaks can help you isolate the problem by making the problem easier to reproduce.
I have developed application and all is well. As well, I also keep memory foot print very low.No leaks show during application run. I tested application more than two hour and there is no crashing report. But when i checked application on instruments at that time it's show me following leaks.I have checked my app but there is no such leaking object. "Even I used app continue 12 hour and it didn't crash or stop".
//Here the screen shot of instruments.
///>>>>>>Here, I uploaded latest screenshot of leaks.It may help somebody to understand where the leak is.
// I think it's library file leaks(CoreFoundation)...Please Suggest What to do..
Please help me, This is really screw me up.
Thanks.
Not all of the 'memory leaks', are actual leaks. And some of the reported issues may be caused by Apple libraries themselves. Typically all the singletons, static variables, and some c level variables are 'leaked', but only once and are not considered a threat to memory.
Foundation classes such as NSString, NSArray, etc. are optimized to handle heavy workload. And some objects may be kept in the memory to be reused later. Such as #"".
So unless the issue is accumulating over time, just go for it, submit your app as it is. You still can fix it later, if necessary.
Hey analyze you code using "command+shift+b" and fix all leaks whatever coming after analyzing, submit it to app store. I don't think we can fix all leaks shown by instrument, so better to go with command+shift+b. I think we should use instrument only when getting memory warning and crashes due to insufficient memory.
I work on an average (~ 20k lines of code, Objective-C mixed with C++), and I am figthing to hunt down an EXC_BAD_ACCESS error.
I have tried all the common techniques (like enabling NSZombie, guard edges,etc.) So far, I have ruled out the possibility to access a released object, and the double-free error.
It seems that something writes on a memory space where it shouldn't. But, as many memory errors, it's not happening all the time, and it's not crashing always in the same place.
(Sometimes I receive the "object was modified after being freed" message).
Sometimes, the overwritten memory belongs to the allocator, and it crashes on malloc, or on free().
And, of course, some changes in the app may influence the bug's behaviour - if I try to comment out parts of the code, the error appears less often, so it's more difficult to find it.
Finally, I have been looking into using valgrind, but it seems that all those who used it worked on the simulator. but my code must run on the actual device (some code is ARM-specific)
Are there any general tips on how to debug such errors?
Note: The app involves video processing, so the amount of memory used is fairly large.
There are some special tools available on the XCode. You could try to use them in order to analyse your code.
http://developer.apple.com/library/mac/#featuredarticles/StaticAnalysis/index.html
It will produce some warning in case of invalid objects usage so it could help you to find a problem.
If you feel that the C++ code is causing the issue you could copy the C++ out of your iPhone project and create a Mac project. With this you could set up various stress tests. And, you should be able to use valgrind as well.