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. QCoreApplication::instance() is NULL
QtWS25 Last Chance

QCoreApplication::instance() is NULL

Scheduled Pinned Locked Moved General and Desktop
qt4migrationqt5
24 Posts 5 Posters 15.2k Views
  • 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.
  • S Offline
    S Offline
    SGaist
    Lifetime Qt Champion
    wrote on 18 Jun 2015, 23:05 last edited by
    #4

    I wonder if it can be related to this bug report although it happens on linux in that case

    Interested in AI ? www.idiap.ch
    Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

    P 1 Reply Last reply 10 Jan 2016, 08:40
    0
    • P Offline
      P Offline
      pullmoll
      wrote on 29 Jun 2015, 09:05 last edited by pullmoll 1 Oct 2016, 08:49
      #5

      I have been to the hospital, thus I can answer only now.
      @SGaist: static QWidgets No, I don't have static QWidgets AFAICT.
      I wrote code to debug every constructor in our project to see what happens before the QApplication is instantiated and there is nothing relevant, i.e. no QObject is created before the QApplication. There are some QObject derived classes instantiated inside the private members of the QApplication derived class, though. But this should be perfectly valid, no?

      @alex_malyu: The qDebug() is executed after the QApplication app(argc,argv); is done, yes. I can inspect the app in the debugger's variable view. Here is an excerpt of the debugger panel:

      app	class QApplication	QApplication
        QGuiApplication	class QGuiApplication	QGuiApplication
          QCoreApplication	class QCoreApplication	QCoreApplication
            QObject	class QObject	QObject
              __vfptr	0x661787f4	__fptr() [11]
                [0]	0x65ecd020	__fptr()
                [1]	0x65eccae0	__fptr()
                [2]	0x65ed60d0	__fptr()
                [3]	0x65ed1920	__fptr()
                [4]	0x65ecf0c0	__fptr()
                [5]	0x66171a4c	__fptr()
                [6]	0x66171a52	__fptr()
                [7]	0x66171a58	__fptr()
                [8]	0x66171a5e	__fptr()
                [9]	0x66171a64	__fptr()
                [10]	0x66171a6a	__fptr()
              staticMetaObject	<Static const member value not available error>	<Static const member value not available error>
              d_ptr	class QScopedPointer<>	QScopedPointer<QObjectData,QScopedPointerDeleter<QObjectData>>
                d	0xa34b70	QObjectData *
                  __vfptr	0x66178790	__fptr() [1]
                  q_ptr	0x15fe60	QObject *
                  parent	0x0	QObject *
                  children	<3 Elemente>	QList<QObject *>
                  isWidget	0	unsigned int
                  blockSig	0	unsigned int
                  wasDeleted	0	unsigned int
                  isDeletingChildren	0	unsigned int
                  sendChildEvents	1	unsigned int
                  receiveChildEvents	1	unsigned int
                  isWindow	0	unsigned int
                  unused	24468448	unsigned int
                  postedEvents	0	int
                  metaObject	0x0	QDynamicMetaObjectData *
              staticQtMetaObject	<Static const member value not available error>	<Static const member value not available error>
            staticMetaObject	<Static const member value not available error>	<Static const member value not available error>
            self	<Static const member value not available error>	<Static const member value not available error>
          staticMetaObject	<Static const member value not available error>	<Static const member value not available error>
        staticMetaObject	<Static const member value not available error>	<Static const member value not available error>
      argc	1	int
      argv	0xbb3d18	char * *
      

      It irritates me that the static member self value is not available according to the debugger.

      However, I now have to deal with an entirely different area in the project and can't try more things to tackle the problem, so I thank you for your thoughts and hints for now.

      1 Reply Last reply
      0
      • A Offline
        A Offline
        alex_malyu
        wrote on 2 Jul 2015, 00:09 last edited by
        #6

        Have you checked executable dependencies?

        Make sure debug version is linked against debug Qt libraries and release against release libraries.
        This is important you can't mix them, cause they use different c runtime.

        1 Reply Last reply
        0
        • P Offline
          P Offline
          pullmoll
          wrote on 10 Jan 2016, 08:13 last edited by pullmoll 1 Oct 2016, 08:56
          #7

          The executable dependencies are fine. I have clearly separated the (out of source) build directories and also all the libraries our project links against have separate debug and release versions.

          Now I tried with MSVC2013 community edition and Qt5 5.5.1 to see if the problem was perhaps compiler related or fixed. Unfortunately it is not.

          I wish there was a way to single step through the startup in disassembler mode to see why the generated code misses to run through the constructor QCoreApplication::QCoreApplication(...) which is where self is assigned a value.

          I'm now thinking of compiling Qt5 5.5.1 myself and inserting qDebug() messages into the constructors of QApplication, QGuiApplication and QCoreApplication to see if they are executed at all.

          Any further hints or ideas are still very welcome, as this problem is a real showstopper and Qt4 is no longer maintained.

          1 Reply Last reply
          0
          • S SGaist
            18 Jun 2015, 23:05

            I wonder if it can be related to this bug report although it happens on linux in that case

            P Offline
            P Offline
            pullmoll
            wrote on 10 Jan 2016, 08:40 last edited by pullmoll 1 Oct 2016, 08:46
            #8

            @SGaist said:

            I wonder if it can be related to this bug report although it happens on linux in that case

            I certainly looks like it is related, because it is the same effect that I see happening.

            FWIW In the very first line of code in main() of main.cpp:

            • instantiating a QCoreApplication app(argc, argv); results in app.instance() being non-NULL.
            • instantiating a QGuiApplication app(argc, argv); results in app.instance() being NULL.

            It seems as if the QCoreApplication that QGuiApplication inherits from simply isn't initialized.

            #ifdef Q_QDOC
            QGuiApplication::QGuiApplication(int &argc, char **argv)
            #else
            QGuiApplication::QGuiApplication(int &argc, char **argv, int flags)
            #endif
                : QCoreApplication(*new QGuiApplicationPrivate(argc, argv, flags))
            {
                d_func()->init();
            
                QCoreApplicationPrivate::eventDispatcher->startingUp();
            }
            

            The parameter passed to QCoreApplication in the initializers here looks a little strange to me, because the QCoreApplication constructor expects int& argc, char ** argv, int flags. But perhaps this is just my lack of understanding of C++.

            I guess this is using the copy constructor, but then there is a Q_DISABLE_COPY(QCoreApplication) in qcoreapplication.h ...

            1 Reply Last reply
            0
            • P Offline
              P Offline
              pullmoll
              wrote on 10 Jan 2016, 16:55 last edited by pullmoll 1 Oct 2016, 17:06
              #9

              FWIW I now managed to single step into the code right from the start.

              The constructor QApplication::QApplication calls the constructor code of QApplicationPrivate, which initializes self in the last step, and which looks like this in the disassembler:

                      Qt5Widgets!QApplicationPrivate::QApplicationPrivate:
              0x64d8c3d0                    push    esi
              0x64d8c3d1  <+0x0001>         push    dword ptr [esp+10h]
              0x64d8c3d5  <+0x0005>         mov     esi,ecx
              0x64d8c3d7  <+0x0007>         push    dword ptr [esp+10h]
              0x64d8c3db  <+0x000b>         push    dword ptr [esp+10h]
              0x64d8c3df  <+0x000f>         call    dword ptr [Qt5Widgets!QVBoxLayout::tr+0x58a4 (6502fef4)]
              0x64d8c3e5  <+0x0015>         mov     dword ptr [esi],offset Qt5Widgets!QApplicationPrivate::`vftable' (65031590)
              0x64d8c3eb  <+0x001b>         lea     ecx,[esi+0A0h]
              0x64d8c3f1  <+0x0021>         mov     eax,dword ptr [Qt5Widgets!QVBoxLayout::tr+0x3e0c (6502e45c)]
              0x64d8c3f6  <+0x0026>         mov     dword ptr [esi+9Ch],eax
              0x64d8c3fc  <+0x002c>         call    dword ptr [Qt5Widgets!QVBoxLayout::tr+0x3ccc (6502e31c)]
              0x64d8c402  <+0x0032>         lea     ecx,[esi+0A4h]
              0x64d8c408  <+0x0038>         call    dword ptr [Qt5Widgets!QVBoxLayout::tr+0x3ccc (6502e31c)]
              0x64d8c40e  <+0x003e>         lea     ecx,[esi+0A8h]
              0x64d8c414  <+0x0044>         call    dword ptr [Qt5Widgets!QVBoxLayout::tr+0x3ed4 (6502e524)]
              0x64d8c41a  <+0x004a>         lea     ecx,[esi+0B0h]
              0x64d8c420  <+0x0050>         call    dword ptr [Qt5Widgets!QVBoxLayout::tr+0x3ed4 (6502e524)]
              0x64d8c426  <+0x0056>         lea     ecx,[esi+0B8h]
              0x64d8c42c  <+0x005c>         call    dword ptr [Qt5Widgets!QVBoxLayout::tr+0x3ed4 (6502e524)]
              0x64d8c432  <+0x0062>         mov dword ptr [esi+0C0h],0
              0x64d8c43c  <+0x006c>         mov dword ptr [esi+0C4h],0
              0x64d8c446  <+0x0076>         mov     dword ptr [esi+58h],1
              0x64d8c44d  <+0x007d>         mov dword ptr [esi+0C8h],0
              0x64d8c457  <+0x0087>         mov dword ptr [esi+0CCh],0
              0x64d8c461  <+0x0091>         mov     eax,dword ptr [Qt5Widgets!QApplicationPrivate::self (65181dc0)]
              0x64d8c466  <+0x0096>         test    eax,eax
              0x64d8c468  <+0x0098>         cmove   eax,esi
              0x64d8c46b  <+0x009b>         mov     dword ptr [Qt5Widgets!QApplicationPrivate::self (65181dc0)],eax
              0x64d8c470  <+0x00a0>         mov     eax,esi
              0x64d8c472  <+0x00a2>         pop     esi
              0x64d8c473  <+0x00a3>         ret     0Ch
              
              

              Note: the absolute address of the static member self here is 0x65181dc0.
              The code then continues in the constructor - calls into QApplicationPrivate::construct() - and finally returns to my main().
              There the next thing that happens is the call to QCoreApplication::instance() in my qDebug()

              0x192ec2  <+0x0042>         call    dword ptr [imageviewer!_imp_?instanceQCoreApplicationSAPAV1XZ (004b7c08)
              

              and the code there looks like this:

                      Qt5Cored!QCoreApplication::instance [c:\work\build\qt5_workdir\w\s\qtbase\src\corelib\kernel\qcoreapplication.h @ 110]:
              0x66b53de0                    push    ebp
              0x66b53de1  <+0x0001>         mov     ebp,esp
              0x66b53de3  <+0x0003>         mov     eax,dword ptr [Qt5Cored!QCoreApplication::self (67367ddc)]
              0x66b53de8  <+0x0008>         pop     ebp
              0x66b53de9  <+0x0009>         ret
              

              Note: the absolute address of self here is 0x67367ddc, which is obviously entirely different from the above 0x65181dc0.

              So something in my executable is really - and I mean really - borked.

              What irritates me is that the debugger lists the library name Qt5Widgets!QApplicationPrivate::QApplicationPrivate and not Qt5Widgetsd!QApplicationPrivate::QApplicationPrivate (the debug version).
              I would not know why this could happen.

              However, if I look at the executable with depends.exe it indeed lists both, Qt5Widgets.dll and Qt5Widgetsd.dll. Now I have to track down how and why the executable refers to both, non-debug and debug versions, of Qt5Widgets.

              1 Reply Last reply
              0
              • S Offline
                S Offline
                SGaist
                Lifetime Qt Champion
                wrote on 10 Jan 2016, 21:25 last edited by
                #10

                What version of Windows are you running ?

                Do you have any plugin from an external source in your application ?

                Interested in AI ? www.idiap.ch
                Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                P 1 Reply Last reply 11 Jan 2016, 10:23
                0
                • A Offline
                  A Offline
                  ambershark
                  wrote on 11 Jan 2016, 02:55 last edited by
                  #11

                  Do you have any Qt global variables that could be initialized before your main? I had that exact problem and my issue was a global Qt variable.

                  I can't remember the exact type, but let's just say a QObject, that was not a pointer and therefore had initialization before the main() and QCoreApplication.

                  It was also in a .so outside of the main application, which may have contributed to the issue as well.

                  My L-GPL'd C++ Logger github.com/ambershark-mike/sharklog

                  P 1 Reply Last reply 11 Jan 2016, 10:28
                  0
                  • S SGaist
                    10 Jan 2016, 21:25

                    What version of Windows are you running ?

                    Do you have any plugin from an external source in your application ?

                    P Offline
                    P Offline
                    pullmoll
                    wrote on 11 Jan 2016, 10:23 last edited by pullmoll 1 Nov 2016, 11:11
                    #12

                    @SGaist said:

                    What version of Windows are you running ?

                    Windows 7 SP1

                    Do you have any plugin from an external source in your application ?

                    No, but we have our own QImageReader/Writer plugins. They are however not the source of the issue.

                    I identified the module (it's a submodules project with abt. 20 modules) which actually wants to link against both, debug and release versions of Qt5Widgets.

                    First I found, by running depends.exe, that it seemed to be QWidget::winId() that was linked imported from Qt5Widgets instead of Qt5Widgetsd. I disabled its use and now this specific module does not any longer want to import from Qt5Widgets (release). The depends.exe tool lists the symbols which are imported from a specific DLL.

                    However I still have the same crash. I'm investigating and will certainly find the source of the problem sooner or later. The dependency walker is a great help in this case (http://www.dependencywalker.com/)

                    1 Reply Last reply
                    0
                    • A ambershark
                      11 Jan 2016, 02:55

                      Do you have any Qt global variables that could be initialized before your main? I had that exact problem and my issue was a global Qt variable.

                      I can't remember the exact type, but let's just say a QObject, that was not a pointer and therefore had initialization before the main() and QCoreApplication.

                      It was also in a .so outside of the main application, which may have contributed to the issue as well.

                      P Offline
                      P Offline
                      pullmoll
                      wrote on 11 Jan 2016, 10:28 last edited by
                      #13

                      @ambershark said:

                      Do you have any Qt global variables that could be initialized before your main? I had that exact problem and my issue was a global Qt variable.

                      I can't remember the exact type, but let's just say a QObject, that was not a pointer and therefore had initialization before the main() and QCoreApplication.

                      It was also in a .so outside of the main application, which may have contributed to the issue as well.

                      Hi ambershark,

                      as I described above, I already tracked down the reason why the executable doesn't work: linking against both, debug and release version of Qt5Gui and Qt5Widgets. Now I only need to find the reason why it happens, which is much easier now the core problem was tracked down.

                      1 Reply Last reply
                      0
                      • P Offline
                        P Offline
                        pullmoll
                        wrote on 12 Jan 2016, 09:27 last edited by
                        #14

                        News: I can't seem to get rid of the dependencies to Qt5Widgets, Qt5Gui and Qt5Core in my executable, even after excluding a lot of submodules and their headers which could have been the cause. The symbols listed in depends.exe for the release DLLs are not giving me any hint where the import results from.

                        Now comes my general question: what could possibly cause a debug build to refer to the release versions of the Qt5 DLLs? As far as I understand Qt, it would have to be some header file included without QT_DEBUG being defined. Is there perhaps a chance to closely inspect the generated Makefiles to see why and where this is happening?

                        Despite the fact I now know the reason for the problem, I can't find the cause, i.e. why does my executable being built in debug mode want to link against Qt5 release DLLs. I'm stumped.

                        1 Reply Last reply
                        0
                        • sierdzioS Offline
                          sierdzioS Offline
                          sierdzio
                          Moderators
                          wrote on 12 Jan 2016, 09:38 last edited by
                          #15

                          Add

                          QT -=core gui widgets
                          

                          to your .pro file?

                          (Z(:^

                          P 1 Reply Last reply 12 Jan 2016, 10:05
                          0
                          • sierdzioS sierdzio
                            12 Jan 2016, 09:38

                            Add

                            QT -=core gui widgets
                            

                            to your .pro file?

                            P Offline
                            P Offline
                            pullmoll
                            wrote on 12 Jan 2016, 10:05 last edited by
                            #16

                            @sierdzio said:

                            Add

                            QT -=core gui widgets
                            

                            to your .pro file?

                            I first thought you were kidding me, but this even works for my main *.pro file.
                            This seems a little.. umm.. counter-intuitive and the opposite of what the the help for the QT qmake variable suggests, no!?

                            1 Reply Last reply
                            0
                            • sierdzioS Offline
                              sierdzioS Offline
                              sierdzio
                              Moderators
                              wrote on 12 Jan 2016, 10:19 last edited by
                              #17

                              Not sure what you mean.

                              By default, QT contains both core and gui, ensuring that standard GUI applications can be built without further configuration.

                              So, if you don't want to link them, remove them. As I understand from (brief, I admit) look at your previous comments, you aim to remove all traces of Qt libs from the project, to pinpoint the place where the release libs are injected.

                              I know this might be a stupid approach, but when everything else fails... :-)

                              (Z(:^

                              P 1 Reply Last reply 12 Jan 2016, 10:24
                              0
                              • sierdzioS sierdzio
                                12 Jan 2016, 10:19

                                Not sure what you mean.

                                By default, QT contains both core and gui, ensuring that standard GUI applications can be built without further configuration.

                                So, if you don't want to link them, remove them. As I understand from (brief, I admit) look at your previous comments, you aim to remove all traces of Qt libs from the project, to pinpoint the place where the release libs are injected.

                                I know this might be a stupid approach, but when everything else fails... :-)

                                P Offline
                                P Offline
                                pullmoll
                                wrote on 12 Jan 2016, 10:24 last edited by
                                #18

                                @sierdzio said:

                                Not sure what you mean.

                                By default, QT contains both core and gui, ensuring that standard GUI applications can be built without further configuration.

                                Yeah, sure, this has been the case since Qt4 AFAICT. I mean that removing "core gui widgets" from a main *.pro file where QMainWindow and QWigets etc. are used is counter-intuitive.

                                @sierdzio said:

                                So, if you don't want to link them, remove them. As I understand from (brief, I admit) look at your previous comments, you aim to remove all traces of Qt libs from the project, to pinpoint the place where the release libs are injected.

                                This is a good idea at least! I would never have thought of trying to remove everything from QT execpt what is really needed (e.g. xml, network, ...).

                                I know this might be a stupid approach, but when everything else fails... :-)

                                Thank you for the hint. It may really help me find the bad guy :-)

                                1 Reply Last reply
                                0
                                • P Offline
                                  P Offline
                                  pullmoll
                                  wrote on 13 Jan 2016, 11:39 last edited by pullmoll
                                  #19

                                  The issue is solved!

                                  After an odyssey of trial and error, the culprit is or was static libraries!

                                  Within our project there were two submodules built as static libraries (CONFIG += static resources create_prl) and linked to several other submodules. The static libraries were built with the same project settings, i.e. DEBUG enabled, and still they were the root cause of my problems.

                                  It has to be either the link_prl in the project, or generally linking against static libraries which causes our project to import the unwanted non-debug Qt5-DLLs in a debug build.

                                  After converting the static libraries to DLLs with export symbols now everything works as expected.

                                  I don't know if this problem and its workaround should be considered a Qt5 bug, or if it is my fault because of not having read some documentation part mentioning this specific fact?

                                  Thanks for all your help and cheers!
                                  Jürgen

                                  1 Reply Last reply
                                  1
                                  • sierdzioS Offline
                                    sierdzioS Offline
                                    sierdzio
                                    Moderators
                                    wrote on 13 Jan 2016, 11:52 last edited by
                                    #20

                                    Nice.

                                    You might want to ask this on Qt development mailing list, the Qt core developers could probably comment on that weird release symbol linking.

                                    (Z(:^

                                    1 Reply Last reply
                                    1
                                    • S Offline
                                      S Offline
                                      SGaist
                                      Lifetime Qt Champion
                                      wrote on 13 Jan 2016, 14:23 last edited by
                                      #21

                                      Since I don't know if you are using a shadow build, are you using the same names for your static debug release libraries ? Are you putting them in the same folder ?

                                      If so you might be linking to a release version of your lib accidentally which in turn would pull the release Qt libraries.

                                      Interested in AI ? www.idiap.ch
                                      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                                      P 1 Reply Last reply 13 Jan 2016, 15:18
                                      0
                                      • P Offline
                                        P Offline
                                        pullmoll
                                        wrote on 13 Jan 2016, 15:16 last edited by pullmoll
                                        #22

                                        After posting to Qt development ML and getting a reply, an even simpler solution is to just

                                        CONFIG -= debug_and_release
                                        

                                        in the *.pro files of the staticlib submodules. I don't know why, but debug_and_release seems to be a default. My project, developed with QtCreator since Qt4, doesn't define this flag.

                                        1 Reply Last reply
                                        1
                                        • S SGaist
                                          13 Jan 2016, 14:23

                                          Since I don't know if you are using a shadow build, are you using the same names for your static debug release libraries ? Are you putting them in the same folder ?

                                          If so you might be linking to a release version of your lib accidentally which in turn would pull the release Qt libraries.

                                          P Offline
                                          P Offline
                                          pullmoll
                                          wrote on 13 Jan 2016, 15:18 last edited by
                                          #23

                                          @SGaist said:

                                          If so you might be linking to a release version of your lib accidentally which in turn would pull the release Qt libraries.

                                          I'm using QtCreator and have separate shadow build directories for debug and release. The culprit was the debug_and_release flag in CONFIG which I have to remove in the *.pro files...

                                          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