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
Forum Updated to NodeBB v4.3 + New Features

QCoreApplication::instance() is NULL

Scheduled Pinned Locked Moved General and Desktop
qt4migrationqt5
24 Posts 5 Posters 15.4k Views 4 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.
  • SGaistS SGaist

    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 last edited by pullmoll
    #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

      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 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 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 last edited by
          #15

          Add

          QT -=core gui widgets
          

          to your .pro file?

          (Z(:^

          P 1 Reply Last reply
          0
          • sierdzioS sierdzio

            Add

            QT -=core gui widgets
            

            to your .pro file?

            P Offline
            P Offline
            pullmoll
            wrote on 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 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
              0
              • sierdzioS sierdzio

                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 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 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 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
                    • SGaistS Offline
                      SGaistS Offline
                      SGaist
                      Lifetime Qt Champion
                      wrote on 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
                      0
                      • P Offline
                        P Offline
                        pullmoll
                        wrote on 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
                        • SGaistS SGaist

                          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 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
                          • SGaistS Offline
                            SGaistS Offline
                            SGaist
                            Lifetime Qt Champion
                            wrote on last edited by
                            #24

                            Still a bit strange but glad you found a solution :)

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

                            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