Debug Assertion Failed: _CrtIsValidHeapPointer(pUserData)

Question

Sometimes I get this "Debug Assertion Failed" error running my Qt project in debug mode ( image ). I don't know where I wrong because the compiler says nothing and I don't know what to do to find my error.

I program under Windows Vista, using Qt Creator 2.4.1, Qt 4.8.1.

My program has to read some informations from a laser device and save them into a file with a code similar to this:

void runFunction()
{
    configure_Scanning(...);

    while(...)
    {
        // do something
        scanFunction();
        // do something
    }
}

and this is my "incriminated" function (where I think the problem is)

void scanFunction()
{
    file.open();

    data = getDataFromDevice();

    if(flag)
    {
        if(QString::compare(lineB,"")!=0)
        {
            QTextStream out(&file);
            out << lineB << endl;
            lineB = "";
        }
        lineA.append(data+"\t");
    }
    else
    {
        if(QString::compare(lineA,"")!=0)
        {
            QTextStream out(&file);
            out << lineA << endl;
            lineA = "";
        }
        lineB.prepend(data+"\t");
    }

    file.close();
}

Where lineA and lineB are initially two void QString: the idea is that I make a bidirectional scanning to save informations in a 2D matrix (from -X to +X and viceversa, while Y goes to a specified target). lineA memorizes the (-)to(+) reading; lineB memorizes the (+)to(-) reading. When the scanning direction changes, I write lineA (or lineB ) to the file and I proceed with the scanning.

Do you understand what I said? Could you suggest me a solution?

Thanks and sorry for my English :P

Answer 1

_CrtIsValidHeapPointerUserData means, that you have a heap corruption, which is noticed by debug heap checker. Suspect everybody who can write any information into any deleted dynamic object. And yes, you'll receive heap corruction not immideately on rewrite occurs, but on the next heap check, which will be performed on any next memory allocation/deallocation. However should be simply tracked by a call stack in single threaded applications.

Answer 2

In our case, the program worked perfectly in DEBUG mode and crashed with the similar error trace in RELEASE mode.

In my case, the RELEASE mode was having msvscrtd.dll in the linker definition. We removed it and the issue resolved.

Alternatively, adding /NODEFAULTLIB to the linker command line arguments also resolved the issue.