I am using OpenTok framework and it crashes like following:
malloc: *** error for object 0x17a535b4: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug.
I have also enabled Zombie, Malloc guard, Malloc Stack and also scribble in Scheme setting of project. But i am not able to get exact line of code. I have also tried Intrument but it also fails to get exact error.
Can anyone help me out in this regards.?
Update to latest iOS version for OpenTok. The new version fixes some of the memory issues that previous versions are experiencing.
Related
I have written a objective-c wifi library and a c wrapper around it to call from my c++ code using corewlan framework.I have setup timers and on expiry of the timer i call scanwifi function of the library which gives details of all the wifi network details.The program keeps crashing by giving malloc error incorrect check sum for freed object. The crash is not consistent,keeps appearing a random places. I tried guard malloc to find the memory bug, left the program running for more than 10 hours but it didn't crash. as soon as i removed guard malloc and executed the program and boom there was the crash. Can anyone please tell ways to catch this memory bug
Thanks
Memory management errors can be particularly difficult to track down; without seeing code it's hard to say.
You mentioned GuardMalloc—have you tried enabling other Diagnostics?
Scribble
Guard Edges
Guard Malloc
Zombie Objects
This can help debugging by making your code crash more predictably—hopefully closer to the source of the error.
(In Xcode 4.4.1, these are set via "Product"->"Edit scheme"->"Run"->"Diagnostics".)
I have a pernicious EXC_BAD_ACCESS bug. I have enabled zombie tracking, but instead of producing a specific stack trace, the program always stops in main at
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
Does anyone know why I don't have a meaningful stack trace? The app uses core data and much of the core data activity is wrappedup in performBlockAndWait methods - could that have something to do with it?
I also have a log message from NSZombieEnabled that says *** -[_PFArray release]: message sent to deallocated instance 0x395d0fe0. Is there any way of finding out what was originally allocated at the address in the log message?
Thanks
yes there is. Run your app with he instruments ON THE SIMULATOR. Select the Zombies instrument and perform the exact steps that make your app crash. The Zombies instrument is available only on the Simulator since you have more RAM on the Mac than on an iOS device.
You can check this tutorial about crashes and figuring out what to do. Pay close attention to this part:
An exception happens when the program is caught doing something it
shouldn’t have done. What you’re looking at now is the aftermath of
this exception: the app did something wrong, the exception has been
thrown, and Xcode shows you the results. Ideally, you’d want to see
exactly where that exception gets thrown. Fortunately, you can tell
Xcode to pause the program at just that moment, using an Exception
Breakpoint. A breakpoint is a debugging tool that pauses your program
at a specific moment.
I am trying to track down where an NSString is getting deallocated. I have enabled GuardMalloc, NSZombie, and Log Malloc Stack for my application (as described here). When I run info malloc-history 0x29d39fe0 in the console, I get the following error:
warning: MallocStackLoggingNoCompact not set in target's environment so the malloc history will not be available.
This is leading me to believe the error is with one of my library projects. How could I enable the above for library projects?
Thanks to Adam for the lead (in the comments above). I was able to use instruments to track down where the extra release was occurring (which happened on an autoreleased object).
I followed the instructions here. Making sure the extended view was open, I was able to determine the exact line of code that had the offending release call.
I'm getting some really strange errors in XCode. Whenever I run my program, I get:
malloc: test_node_integrity: FreeListNode 0x1052af0 { _prev =
0xffffffff, _next = 0xffffffff, _size = 0 } failed integrity check.
I've searched all over Google, but haven't found anyone else with this error message. The stack trace has methods that aren't in my program - it's some other thread that XCode is running. Is there anyway I could get more information on this? I've already tried uninstalling/reinstalling XCode (10.5.8, XCode 3.1).
I am using Garbage Collection, so I'm wondering if there is an error there. I used to be getting a different error, "missing cpu_capibilites.h," which would point to a string formatting method. The error changed into one with the debugger not being able to roll back the state, and now I have this error.
If there's any other error information that I should have posted, let me know.
What's happening is that something in your program or a framework it uses is writing into unused memory (the Garbage Collection heap) and destroying internal data structures in the unused memory. The next time something asks AutoZone (the GC memory allocator) to allocate memory, it tries to read the structures in unallocated memory, finds them to be invalid, and throws the above message.
You can read the source that's doing this at http://www.opensource.apple.com/source/autozone/autozone-77.1/AutoAdmin.cpp?f=text
So you need to look for memory smashers.
If this is related to NSOpenPanel being used in conjunction with GC, I think it may be a known problem. See this thread at Cocoabuilder that seems to relate.
The error something thrown by RegexKitLite when I passed it a problematic string. The error message indicated a system-wide error, which is what confused me for so long.
As the title says, my app crashes when garbage collection is not enabled. The app pops up for a few seconds and then it just crashes, with nothing but this in the debugger console:
[Session started at 2009-08-17 15:03:20 -0600.]
GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin".sharedlibrary apply-load-rules all
Attaching to process 12535.
unable to read unknown load command 0x22
unable to read unknown load command 0x22
unable to read unknown load command 0x22
unable to read unknown load command 0x22
I don't know why its happening. I think its probably a memory management issue. I used AnalysisTool (front-end to Clang Static Analyzer) to check for leaks and memory management issues, and I fixed the issues it found. Running the app through Instruments however reveals a memory leak around the time it starts. I have no idea where this leak is coming from...With garbage collection enabled the app runs fine, but Instruments still finds a leak.
Source code is available upon request
Thanks
Since the error says it occurs when calling [CFArray countByEnumeratingWithState:objects:count:] on a deallocated object, that gives you a fairly good idea of where to look. That method is part of part of NSFastEnumeration, so unless you're calling that method directly (highly unlikely), it is being invoked from within a for (... in ...) loop on your array object. If you can figure out where that is, you can set a breakpoint on (or just before) the for loop and check whether your object has been deallocated. The most likely cause of the problem is failing to properly retain the array, and it is probably released by the run loop draining an NSAutoReleasePool.
XCode has a bunch of memory profiling support built in - turning those on might reveal more information. I found these links particularly helpful:
http://developer.apple.com/technotes/tn2004/tn2124.html#SECMALLOC
http://www.cocoadev.com/index.pl?NSZombieEnabled
http://www.cocoadev.com/index.pl?DebuggingTechniques
http://www.cocoadev.com/index.pl?DebuggingAutorelease
You're probably releasing an object when you shouldn't, then sending it a subsequent message. unfortunately, the crash (where the subsequent message is sent) isn't where the problem is - it's where you are releasing (or worse, deallocing) where you shouldn't. The clang static analyser isn't foolproof, and blindingly following the advice won't necessarily have helped.
If it crashes after showing something for a few seconds, it may indicate that something that needed to be retained was released by the autorelease pool at the end of the run loop. Have a look at places where you assign variables with objects returned by other methods. Any method without "new", "copy", "alloc" (there's a few others I think) in the name usually indicates that you'll need to retain it if you want to keep using it.
It could also mean that you have released something that you shouldn't have and it was released again by the autorelease pool. Have a look at all the places you are releasing objects and make sure that you are only releasing objects that you have either retained yourself, or releasing objects returned by methods that explicitly state ownership, such as "new", "alloc", "copy", "mutableCopy" and so on.