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.
Related
I am currently writing a game rendering engine using LWJGL 3 and Kotlin. Everything works fine for multiple minutes, until out of nowhere the program exits with the following message:
Process finished with exit code -1073740940 (0xC0000374)
All I do is load a few models, and then render them with glDrawElements(...) in the main loop - nothing else is loaded or changed.
Now, I know that this error code means heap corruption, but I do not even get a hs_err_pid logfile and the Java Debugger just crashes with the program. So how would I go about debugging such a crash? Could this be because of an incompatibility with Kotlin?
So, for everyone who may find themselves in a similar situation: Thanks to the LWJGLX debug tool by Kai Burjack, I instantly found what crashed the program.
What I did was the following: In the shader class, when uploading a matrix, I allocated a managed FloatBuffer, which I then accidentally tried to free manually:
val buf = BufferUtils.createFloatBuffer(16)
matrix.get(buf)
glUniformMatrix4fv(location, false, buf)
MemoryUtil.memFree(buf)
The MemoryUtil.memFree() call actually doesn't crash, but as the matrix changes every frame, this method corrupts the heap over time - hence the crash after a few minutes.
I attached the LWJGLX debugger and now my program crashed instantly - with a precise error message telling me that I am trying to free a Memory Region i did not allocate with memAlloc() - So after changing my code to
val buf = MemoryUtil.memAllocFloat(16)
...
MemoryUtil.memFree(buf)
everything now works. I can only recommend the LWGLX debugger - It also found some memory leaks I now have to fix ;-)
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.
Is there a way to prevent an EXC_BAD_ACCESS from crashing an app, like with #try..#catch you can handle an exception gracefully.
Update:
The code crashes when it attempts to dereference an invalid pointer. This is a third party library and it interfaces with external hardware so I can't debug locally. I am trying to prevent it from crashing and output data to a debugging console on my app.
In ObjC, try/catch do not handle exceptions particularly gracefully. You will still leak memory and leave the system in an undefined state. With rare exception, the expectation is that you are simply catching so you can log some things before crashing. And in general, you should not use #catch anywhere but at the top level of your program for this purpose. There are some extraordinary situations where limited use of exceptions may be appropriate, but they are rare in ObjC. See the Exception Programming Guide for some more information. See especially the following from the ObjC ARC documentation:
The standard Cocoa convention is that exceptions signal programmer error and are not intended to be recovered from. Making code exceptions-safe by default would impose severe runtime and code size penalties on code that typically does not actually care about exceptions safety. Therefore, ARC-generated code leaks by default on exceptions, which is just fine if the process is going to be immediately terminated anyway. Programs which do care about recovering from exceptions should enable the option [-fobjc-arc-exceptions, which imposes speed and memory penalties on your program].
The same is true of EXC_BAD_ACCESS. You can catch it with a signal handler for the purpose of recording some information and then finishing your crash. For a good tool for doing this see PLCrashReporter. It is very difficult to write such a handler correctly, so I strongly recommend using an existing framework. You can easily get into deadlocks that drain the user's battery if you catch EXC_BAD_ACCESS incorrectly.
You get EXC_BAD_ACCESS often because you sent a message to a released object. Then you can examine the NSZombie. What is an NSZombie? You can see : this. It will catch the
EXC_BAD_ACCESS because of sent a message to the released object.
You can set NSZombie like this : Check the Enable Zombie Objects
And you can also get EXC_BAD_ACCESS because of the memory warnings level is too high , or your memory is too high , so the apple will shut your app down. This EXC_BAD_ACCESS is too hard to prevent . I think the only way is to manage your memory as low as you can , sometimes you can see the log where is receive memory warning , when the level is high, it may getEXC_BAD_ACCESS
You can rewrite your code to not have these errors. Try not to reference any null pointers and keep references to any object that you want to have access to.
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".)
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.