Hello world application causes a memory leak



  • I have been working to get Qt to work in Visual Studio 2013 and think I have succeeded. I could create a simple application that reads and show a qml-file. The problem is when the application finish Visual Studio detects a memory leak.

    In fact even an extremely simple application like this causes a memory leak:

    @
    #include "stdafx.h"
    #include "HelloLeak.h"

    #include <QGuiApplication>
    #include <QQmlApplicationEngine>
    #include <qquickitem.h>

    int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
    {
    qDebug() << "Hello memory leak!";

    //The next line will also cause a memory leak
    //QGuiApplication app(argc, 0);

    return 0;
    }
    @

    The output from Visual Studio will be something like:
    @
    Detected memory leaks!
    Dumping objects ->
    {270} normal block at 0x00F5B9C8, 8 bytes long.
    Data: < > 88 B9 F5 00 00 00 00 00
    {268} normal block at 0x00F5B988, 3 bytes long.
    Data: <: > 3A 20 00
    {267} normal block at 0x00F61D28, 24 bytes long.
    Data: < V V V> BC C3 11 56 E8 C2 11 56 88 B9 F5 00 04 C4 11 56
    {254} normal block at 0x00F45230, 12 bytes long.
    Data: < ( > C8 B9 F5 00 28 1D F6 00 00 CD CD CD
    ....
    @

    This really puzzles me because I having a hard time to imagine a simpler application. If I remove the qDebug line and rebuild the solution the leak is gone (just build not enough – very strange). Is it something I have missed? I’m a Qt-newbie so that’s very possible :-).

    The complete project could be downloaded from here:
    http://www42.zippyshare.com/v/52842250/file.html


  • Moderators

    Actually it's not caused by Qt. It seems you've modified an MFC app and you've got some leftovers in the stdafx.h:
    @
    #define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // some CString constructors will be explicit
    #define _AFX_NO_MFC_CONTROLS_IN_DIALOGS // remove support for MFC controls in dialogs

    #ifndef VC_EXTRALEAN
    #define VC_EXTRALEAN // Exclude rarely-used stuff from Windows headers
    #endif

    #include <afx.h>
    #include <afxwin.h> // MFC core and standard components
    #include <afxext.h> // MFC extensions
    #ifndef _AFX_NO_OLE_SUPPORT
    #include <afxdtctl.h> // MFC support for Internet Explorer 4 Common Controls
    #endif
    #ifndef _AFX_NO_AFXCMN_SUPPORT
    #include <afxcmn.h> // MFC support for Windows Common Controls
    #endif // _AFX_NO_AFXCMN_SUPPORT
    @
    Remove this and there's no leak.

    Btw. If you use a Qt add-in for visual studio it will also add a Qt application wizard that will create much cleaner and portable(no _tmain and TCHAR stuff) and Qt-oriented basic app.

    For a much better and less intrusive memory leak detection on Windows I recommend "VLD":https://vld.codeplex.com/. Really great tool that shows you actual stack trace (with jump to feature) instead of meaningless binary dump.



  • Thanks for answering :). If I remove the things you say the warning disappears, but I’m not sure the leak is gone :). If I remove it and add for instance:

    @
    int* thisWillCauseALeak = new int[1024];
    @

    in main I don’t get a warning even if it obviously is a leak. So I’m not sure if the problem is gone or just hidden.

    I have been using the Qt add-in (took me hours to get it work :( ) to port applications created in Qt Creator. But in this case I will add Qt-support in an existing mfc-application. So it’s a bit different but I know how to get it to work.

    Either way I could clean the stdafx-file in my existing application to remove the warning. But then I’m afraid that I lose the ability to detect memory leaks in the ordinary way. Luckily I have another tool to detect leaks so it not a big deal. But it feels like something is wrong.


  • Moderators

    The Visual Studio itself doesn't do any leak detection. I'm not an expert on MFC but I guess it does and that's what you're seeing. It probably tracks it's own objects and not the new allocations like in your example. My guess would be that MFC creates some "global" objects and leaves them to OS to clean up.
    I don't know what to do with that output because it just points to memory locations after the app is already closed so it's pretty useless.

    I'm pretty sure Qt doesn't leak. Not in such a simple case anyway. I would check leaks with other tools and try to confirm this. You can plug that VLD I mentioned and see where the leak is really coming from.

    Sorry you've had problems with the add-in. Usually it's just install, add Qt version and use, 2 minutes tops.



  • [quote author="Per-Erik Kristensson" date="1413206849"]Thanks for answering :). If I remove the things you say the warning disappears, but I’m not sure the leak is gone :). If I remove it and add for instance:

    @
    int* thisWillCauseALeak = new int[1024];
    @
    [/quote]

    This isn't necessarily a leak. If you still have access to "thisWillCauseALeak" then you can get to that memory. In order to be a leak, you need that line in a function. When the function returns and you get back to main, you will have leaked memory since you no longer have any way to use it.


  • Moderators

    wrosecrans - main() is a function. main returns without releasing it. This is always a leak.



  • [quote author="Chris Kawa" date="1413208014"]I'm pretty sure Qt doesn't leak. Not in such a simple case anyway.[/quote]

    I also believe that Qt doesn’t leak. But I’m also believe that MFC doesn’t leak :). I’m would be surprised that any of these frameworks would leave anything to the OS to clean up. Either way I leave it as it is since I doesn’t come any further to a solution.

    [quote author="Chris Kawa" date="1413208014"]I would check leaks with other tools and try to confirm this. You can plug that VLD I mentioned and see where the leak is really coming from.[/quote]

    Thanks for the tip regarding VLD. Personally I have been using "Memory leak finder":http://www.codeproject.com/Articles/5735/Memory-leak-finder which seems to do the same thing. One thing I have noticed is that at least this tool doesn’t detect the leak we have discussed. It only detects leaks in the code you compile yourself. But I will try VLD, maybe that’s different.

    [quote author="Chris Kawa" date="1413208014"]Sorry you've had problems with the add-in. Usually it's just install, add Qt version and use, 2 minutes tops.[/quote]

    What? Is there an installer? :) I’ve only find this http://qt-project.org/wiki/QtVSAddin and was stuck on “Build Instructions for Qt 4.x” until I released that I doesn’t need to this step at all.


  • Moderators


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.