Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Memory corruption due to MOC code is driving me insane.
Forum Updated to NodeBB v4.3 + New Features

Memory corruption due to MOC code is driving me insane.

Scheduled Pinned Locked Moved General and Desktop
6 Posts 3 Posters 1.8k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • D Offline
    D Offline
    dtecta
    wrote on last edited by
    #1

    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

    1 Reply Last reply
    0
    • T Offline
      T Offline
      Torto
      wrote on last edited by
      #2

      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.

      1 Reply Last reply
      0
      • M Offline
        M Offline
        MarianMMX
        wrote on last edited by
        #3

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

        1 Reply Last reply
        0
        • T Offline
          T Offline
          Torto
          wrote on last edited by
          #4

          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

          1 Reply Last reply
          0
          • D Offline
            D Offline
            dtecta
            wrote on last edited by
            #5

            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.

            1 Reply Last reply
            0
            • T Offline
              T Offline
              Torto
              wrote on last edited by
              #6

              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&#40;&#41;;
              

              }@

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

              May be locale changed somehow.

              1 Reply Last reply
              0

              • Login

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • Users
              • Groups
              • Search
              • Get Qt Extensions
              • Unsolved