QCoreApplication::instance() is NULL

pullmoll

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/)

pullmoll

@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.

pullmoll

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.

sierdzio

Add

QT -=core gui widgets

to your .pro file?

pullmoll

@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!?

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... :-)

pullmoll

@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 :-)

pullmoll

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

sierdzio

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.

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.

pullmoll

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.

pullmoll

@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...

SGaist

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