64-bit build in OSX - inconsistant malloc error

I'm getting a very inconsistant error in Xcode:

malloc: *** error for object 0x1041146f8: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug

I know that it's not my code directly because a 32-bit build works just fine (Architecture set to Standard 32/64 and Build Active Architectures Only is set to No). It also will occasionally work just fine without me changing even a comment, but only about %10 of the time.

I've traced the error using breakpoints, sometimes it happens on an ivar like: myClass = new MyClass, but sometimes it happens on deleting an unrelated ivar. I've tried setting myClass to null prior to the new instances creation but that didn't help, and I'm at a loss because I don't completely understand caching, registers, heaps, and stacks (which may give insight into why this is happening).

Here's some of the code in the places I'm getting the error. Note that each set of lines of code is a different place, and class, where the error may, or may not, happen.

error 1

void functionA() {
    // bunch of unrelated code
    if (aAinterpFilter)
        delete aAinterpFilter;

    // this is where the first error sometimes happens
    aAinterpFilter = new InterpFilter((Window::Sinc::LP*)filterDesign, aAinterpFactor);
}

error 2

Window::Sinc::LP::~LP ()
{
    // the z delete is where the error sometimes happens
    delete[] z;
    delete[] kernel;
}

error 3

void AAOsc :: setPhase(double phase) {
    if (phase < 0.0) phase = 0.0;
    if (phase > 1.0) phase = 1.0;

    // this is where the error rarely happens, but it does sometimes.
    osc->tickInfo->curvPhase = static_cast<uint>(phase * 4294967296.0);
}

Any ideas that may point to the solution will be greatly appreciated.

You need to add a breakpoint on the suggested function malloc_error_break(). Run the app and let the debugger break on that function. Step back a stack frame or two and you'll see which variable the OS thinks has been freed that you've modified. You then need to figure out where that variable may have been previously freed.

This could also happen if you have a block of memory that you malloced and then write to and you accidentally write a few bytes before the pointer that malloc returned. You can catch that by turning on guard malloc and making it happen again.