Memory corruption due to MOC code is driving me insane.

[dtecta]

I've been hunting down a corrupted memory problem and ended up with the following sanity check. This piece of code will break only in a debug build depending on whether or not MOC generated code is compiled or not.
@
#include "MainWindow.hpp"
#include <QtGui/QApplication>
#include "nfolddae/DaeImporter.hpp"

int main(int argc, char *argv[])
{
QApplication app(argc, argv);

nfold::DaeImporter importer;
importer.open("data/cube.dae");

//MainWindow window;
//window.show();

return app.exec();

}
@

The code that shows corrupted memory is the "importer.open()" call. This code does not depend on Qt. The importer relies heavily on STL, so my first hunch was a static library using a bad CRT. This appears not to be the case as all the static libraries in the linkage use the same CRT. (Multi-threaded Debug DLL).

Note that the creation of MainWindow is intentionally commented out in both the passing and failing version. MainWindow is derived from QObject and uses MetaObjects. However since MainWindow is not used I do not have to add the MOC generated sources to the project. If I do not add them then "importer.open" will run fine. However, if I do add the MOC sources to the project, then the "open" will fail on a memory corruption. The funny thing is that my main function is not dependent on the MOC code, and that in both cases all external libraries in the linkage are exactly the same. I'm configuring my project using CMake 2.8.11 for Visual C++ 9 and I'm using Qt 4.8.1. Here's my CMakeLists.txt
@
set(TESTBED_SRCS
main.cpp
MainWindow.cpp
MainWindow.hpp
)

set(TESTBED_MOC_HDRS
MainWindow.hpp
)

qt4_wrap_cpp(TESTBED_MOC_SRCS ${TESTBED_MOC_HDRS})
qt4_add_resources(TESTBED_QRC_SRCS MainWindow.qrc)
qt4_wrap_ui(TESTBED_UI_HDRS MainWindow.ui)

source_group("Moc Files" FILES ${TESTBED_MOC_SRCS})
source_group("Ui Files" FILES ${TESTBED_UIS})
source_group("Qrc Files" FILES ${TESTBED_QRC_SRCS})

include_directories(
${PROJECT_SOURCE_DIR}/src
)

add_executable(testbed WIN32
${TESTBED_SRCS}
${TESTBED_MOC_SRCS}
${TESTBED_QRC_SRCS}
${TESTBED_UI_HDRS}
)

set(TESTBED_DEPS glwidget nfoldogl nfoldobj nfolddae nfold consolid FreeImage glew tinyxml2)
add_dependencies(testbed ${TESTBED_DEPS})
set_target_properties(testbed PROPERTIES DEBUG_POSTFIX _d)
target_link_libraries(testbed
${TESTBED_DEPS}
${OPENCOLLADA_LIBRARIES}
${QT_QTMAIN_LIBRARY}
${QT_LIBRARIES}
${OPENGL_LIBRARIES}
)
@

The above CMakeList.txt results in the memory corruption. In order to fix it I need to remove all sources except "main.cpp". It appears to me that qmake is adding static libraries that are hidden from Visual Studio and that change the memory allocation behavior, but this sounds crazy. Can someone here please restore my sanity and tell me what's going on here?

Cheers,

Gino

[Torto]

I'v got the same issue, even on linux.
this code is working fine:
@#include <TecplotFile.h>
int main(int argc, char *argv[])
{

TecplotFile tf1("./examples/1ddata.plt");
tf1.open();

QApplication a(argc, argv);

}
@

And this returns a corrupted data:
@int main(int argc, char *argv[])
{
QApplication a(argc, argv);
TecplotFile tf1("./examples/1ddata.plt");
tf1.open();
}@

TecplotFile allocates large array of double, and returns it. In the first case it is good, and in the second case it zeros (or corrupts) this memory.

[MarianMMX]

First of all, make sure sure you do a complete rebuild (delete all *.obj or *.o files).

[Torto]

Did it, do not help.
Interesting: i added debug output in TecplotFile, printing the double array.
@for( auto i: data_)
{
cout << typeid(i).name()<<" ";
cout <<i<<endl;
}@

data_ is vector<double>
The result is:
First case:
d 0.951057
d 1
d 1.95106
d 2.80902
d 3.58778
d 4.30902

Second case (after the QAplication constructor ):
d 0
d 1
d 1
d 2
d 3
d 4

[dtecta]

I managed to work around the corrupted heap problem by replacing std::map by a map implementation that uses std::vector in my code. I'm using a customized allocator with all STL containers that logs allocations in debug for leak detection. Apparently my allocator conflicts with the MOC sources when used in combination with std::map. I still haven't figured out why, since my std::vector uses the same allocator but doesn't show the issue. Note that my code is in its own namespace so I'm pretty sure the problem is not related to name clashes of static objects.

[Torto]

I found a bug. In my case it looks like std::stod does wrong.

@int main(int argc, char *argv[])
{
cout<<"Before: "<<stod("0.5")<<endl;
QApplication a(argc, argv);
cout<<"After: "<<stod("0.5")<<endl;

PlotterWindow w;
w.show();
return a.exec();

}@

torto@torto-notebook:~/projects/tecplotlib$ ./qtplotter
Before: 0.5
After: 0

May be locale changed somehow.