[SOLVED] Qt 5.2.1 Static with vs2012 results in access violation for debug builds



  • Hey guys,

    I am trying to make the static version of the QT framework work, but I'm running into an issue.
    Release mode works fine, but Debug mode gives the following exception:
    @Unhandled exception at 0x0000000140B46609 in ApplicationName.exe: 0xC0000005: Access violation reading location 0x0000000000000008.@

    With the following callstack:
    @
    ApplicationName.exe!QListData::isEmpty() Line 92 C++
    ApplicationName.exe!QList<QScreen * __ptr64>::isEmpty() Line 155 C++
    ApplicationName.exe!QGuiApplication::primaryScreen() Line 810 C++
    ApplicationName.exe!sharedCursor() Line 178 C++
    ApplicationName.exe!QWindowsScreen::QWindowsScreen(const QWindowsScreenData & data) Line 198 C++
    ApplicationName.exe!QWindowsScreenManager::handleScreenChanges() Line 408 C++
    ApplicationName.exe!QWindowsIntegration::QWindowsIntegration(const QStringList & paramList) Line 374 C++
    ApplicationName.exe!QWindowsIntegrationPlugin::create(const QString & system, const QStringList & paramList, int & __formal, char * * __formal) Line 116 C++
    ApplicationName.exe!loadIntegration(QFactoryLoader * loader, const QString & key, const QStringList & parameters, int & argc, char * * argv) Line 64 C++
    ApplicationName.exe!QPlatformIntegrationFactory::create(const QString & platform, const QStringList & paramList, int & argc, char * * argv, const QString & platformPluginPath) Line 81 C++
    ApplicationName.exe!init_platform(const QString & pluginArgument, const QString & platformPluginPath, int & argc, char * * argv) Line 897 C++
    ApplicationName.exe!QGuiApplicationPrivate::createPlatformIntegration() Line 1028 C++
    ApplicationName.exe!QGuiApplicationPrivate::createEventDispatcher() Line 1046 C++
    ApplicationName.exe!QApplicationPrivate::createEventDispatcher() Line 86 C++
    ApplicationName.exe!QCoreApplication::init() Line 712 C++
    ApplicationName.exe!QCoreApplication::QCoreApplication(QCoreApplicationPrivate & p) Line 638 C++
    ApplicationName.exe!QGuiApplication::QGuiApplication(QGuiApplicationPrivate & p) Line 493 C++
    ApplicationName.exe!QApplication::QApplication(int & argc, char * * argv, int _internal) Line 538 C++
    ApplicationName.exe!QtApp::QtApp() Line 46 C++@

    It appears that QGuiApplicationPrivate::screen_list got corrupted, but I am not sure why.
    The dynamic version of the framework works fine for both cases.

    Thanks in advance for anybody that can help!

    Gr. Emile



  • Hi, did you resolve this problem? Actually, just faced the same one.



  • You guys probably have the wrong linkage of the CRT libs in VC. Make sure you are using the same one that is used in Qt.

    For instance if Qt is linked with multithreaded (/MT) CRT and your project is linked with the single threaded version that would cause that crash. Same with the difference between debug and release CRT libs.

    I am not a VC user so I can't remember exactly where to find the option, but IIRC it was under code generation in the project settings. This is old knowledge though, you'll have to know your own compiler. :)



  • [quote author="ambershark" date="1403820828"]You guys probably have the wrong linkage of the CRT libs in VC. Make sure you are using the same one that is used in Qt.
    [/quote]

    No, compiler notifies you about it. If you mixed /MT and /MD you cannot even build anything.

    I'm using Qt5 static build in two ways. First way, it is completely static app, with all build inside, with qml, plugins, etc, just a single standalone .exe binary. It works normally.

    Second way, use it inside other host application, like a plugin. I create QApplication when my DLL starts, then I get a HWND from host app and so on. And using this way I have absolutely the same crash log like above.



  • That's good the VC warns you about that problem, it didn't used to when I used it a long time ago. Also, I ran into it recently on a project and the problem was in a DLL that used a different CRT than the exe. Anyway that aside since you've made sure it isn't your problem.

    So what you are trying to do is launch the Qt static app inside of another program and then get a handle to it's window?

    You mentioned plugin which static Qt doesn't support but I don't think you mean Qt plugins, but just mentioning this to be thorough.

    You can check this to make sure you aren't doing this... It has to do with CRT again, there could still be an issue with that:

    "http://stackoverflow.com/questions/11023461/qt-crashes-when-using-qlist-heap-corruption":http://stackoverflow.com/questions/11023461/qt-crashes-when-using-qlist-heap-corruption

    And then finally I noticed in the backtrace that it looks like primaryScreen is not able to get a valid pointer to a screen. This could indicate a problem with the windows platform plugin (not loading properly?).

    I'm assuming this line:

    @ApplicationName.exe!QList<QScreen * __ptr64>::isEmpty() Line 155 C++@

    is not getting a valid item and therefore isEmpty will crash with an access violation. Again this points at no valid screens in primaryScreen(). I'm not up on windows platforms much, try to avoid it like the plague, but for someone that knows more about how the windows platform plugin works could potentially help on why it can't get a screen.

    Maybe it's a multiple monitor thing? Are you perchance running multimon setup? Really grasping at straws for that one, lol.

    Oh and the fact that the guy above says the dynamic version works but the static doesn't leads me to want to blame the platform plugin again. Building Qt statically even says at configure time that plugins aren't supported. That may be the issue. I'm out of my element with windows though.



  • There are several possibilities, so I asked Ertyui about his solution, in case he has it.
    In my case, right now I cannot debug inside Qt code but I will change this next days and will see what is going on exactly.

    bq. You mentioned plugin which static Qt doesn’t support

    Yes, I meant Qt plugins, they are built statically and linked in app and dll. It works fine with a simple magick, even with cmake. This is how I got single .exe binary with all built inside.

    Actually, I have both versions of Qt, with /MT and /MD for different solution and never had any problem with QList or any other. Anyway, thank you for this link.

    I use two monitors but as I mentioned standalone app with this Qt works totally good. So, I need to investigate what is wrong with platform plugin during initialization but I can't right now, this topic was my "grasping at straws" before I can debug Qt :)



  • Good luck! I know how these things go, it can be a real nightmare to solve sometimes.

    Maybe try disconnecting your second monitor so the system only thinks you have one, and rerun it. It may work and then you have something to investigate further. I have seen multimon cause all kinds of weird stuff in Linux so I can only imagine windows could have some issues too.

    As for QList, it tends to crash... a lot. But I have never seen it be an actual bug in QList. Every time I have had issues with a crash like that it was always some other piece of code that caused it. It's happened often enough that I don't even look into QList anymore but usually outside of it for what might be going on. And coincidentally my last crash with it was related to not having the proper platform plugin on windows.

    Anyway, if you end up with a solution post back here so we all know for future reference. :)



  • Ah, hey guys!
    Yes, I do have the answer :D

    The actual problem is that we use the QApplication as a global static which constructs on static initialization time. This won't work though because some globals it is depended on could be not initialized yet, as the order of initialization is "random". So the list of screens was not yet created in this case.

    I think we were just lucky in Release mode in this case.

    Also the use of dll's makes sure that the Qt modules are initialized as soon as they are loaded, which effectively makes sure that the globals are initialized as well before you use them.

    The fix was really easy, we made sure that the QApplication was either constructed on the stack, or we use a global static pointer and construct it as the first thing in main. This makes sure that all the globals in Qt are initialized before the initialization of QApplication tries to use them.

    Hope this helps!



  • Thank you so much for your response. It is so obvious now but as always only after explanation :-) And it definitely helped!



  • Awesome! Glad I could help!


Log in to reply
 

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