views:

209

answers:

3

Hi Everyone, 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.

Thanks

A: 

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.

NWCoder
A: 

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.

bobidden
+1  A: 

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.

cdespinosa
When you're using GC, the problem is not necessarily memory smashers, at least not in the traditional "use after `free()`" manual memory management sense. Because Cocoa's GC system critically depends on knowing which pointers are GC and which are not, anything that causes it to loose track of that causes problems like this. It is possible to write "error free code" and have it fail at run time because of compiler / GC bugs- referencing a global `__strong` pointer variable through another pointer, for example. I've found it almost impossible to write working programs with Cocoa's GC system.
johne
Well, as the manager at Apple responsible for Xcode, I'm in charge of 2.5MLOC that uses Cocoa's GC system, and when we get failures like the above, it's almost always a piece of code that's caching a pointer to a GC object, not telling the GC system about it, then writing to GC memory after the object has been reaped.
cdespinosa