Take the 2-minute tour ×

I am building a JSON-object with Qt and convert it to a QString using QJson. This (normally) works fine and it does in this case but in the destructor of my Qt data structure, it crashes with an Access Violation. The Object is built fine, it is sent over my network connection and after the function ends, my application crashes.

My code looks like this:

void bar()
    QVariantMap data;
    data.insert("Id", 1);
    QList<QVariant> list; //QVariantList

    for (QMap<...>:ConstIterator ... ) //Loop through a Map
        QMap<QString, QVariant> singleEntry; //QVariantMap
        singleEntry.insert("LocalId", it.value());
        QList<QVariant> entryList; //QVariantList
        for (...) //Loop through another structure
        singleEntry.insert("List", entryList);
    data.insert("Entries", list);

    QJson::Serializer.serialize(data); // Works fine
} // Crash here

If I remove the inner loop, which builds up entryList, everything works fine. It seems that the destructor of data cannot delete the contents but I have no idea, why. The whole data structure seems to be fine while serializing it (and I hope that QJson does not change anything in the given data) but it cannot be cleaned up..

Best Regards, Tobias

share|improve this question
In VS this behaviour is common signal that you linking wrong library to your project - for example adding debug-mode library to release project or visa versa. –  Raiv Aug 10 '11 at 13:31
I am not quite sure as I use VS only for editing, the project is compiled using JAM. I cannot compile release version because of other dependencies and I only link Qt debug libraries. Do I have a chance to check whether the right library is linked to the project? –  Tobias Aug 11 '11 at 6:23
add comment

2 Answers

As Raiv said this can happen when mixing debug and release dlls, but in my oppinion this can also happen if the application and the Qt DLL's use different CRT libraries. Some people say that when they recompiled Qt on their machines the problem dissapears and I think this is because the CRT dlls after Qt rebuild are the same as the app's. Try to set the Runtime Library option in C/C++ Code Generation is set to Multi-threaded Debug DLL (/MDd) or Multi-threaded DLL (/MD) respectively for Debug and Release. Some Qt types as QVariantMap, QVariantList, QModelIndexList are probably allocated with /MD (in Qt's dll) and when they are deallocated with /MT (in the app) I think this causes the crash. This can also fix the crash on QString::toStdWString(). In order for this to link maybe the Ignore All Default Libraries should be set to No and Ignore Specific Library should not mention crt dlls used by Qt.

share|improve this answer
add comment
up vote 0 down vote accepted

I got a little workaround, which fits my needs. I have still no idea, why this crash happens, but I know, which should be the problem.

I tried to build up a static structure like this:


and it crashes. If I remove the QVariantList at the bottom and add QVariantMap or anything else instead, it is working fine. I think this is a problem with the nesting level in this case.

I have now just joined my list as a comma-seperated QString and then it works fine.

If anyone of you has an idea, why the crash in destructing such a nested struct (another information: doesnt matter if a allocate the QVariants in heap and delete them myself or stack) and how to fix it, please let me know.

share|improve this answer
add comment

Your Answer


