0

This simple code crashes on program end (Qt 5.9.1, gcc 5.4.1):

#include <QCoreApplication>
#include <memory>

std::shared_ptr<QCoreApplication> manager;
int main(int argc, char *argv[])
{
    manager = std::make_shared<QCoreApplication>(argc, argv);
}

I know that the usual way is to declare a QCoreApplication instance on the stack, and have it destroyed at the end of main(), but my use case is as follows: I am wrapping a library that makes use of Qt with Boost.Python, and I initialize Qt like above when the python module gets loaded. However, I have no way to destroy the QCoreApplication unless I force the user to call some finalize() method.

The idea was then to have it destroyed when the library (python module) gets unloaded, but this does not seem to work. Is the above expected, and if so, why? "Destruction order problem" is my first guess, but in this case, should this be regarded as a bug?

matpen
  • 281
  • 2
  • 15
  • The application object is a global variable/singleton (you can get it using `qApp` or `QCoreApplication::instance()`) and the initialization probably does a lot of things, I'm not sure if you actually unload it. It's probably better to create the app instance from Python and then just use it. – Lukáš Lalinský Jul 29 '17 at 20:29

1 Answers1

3

The problem (as Lukas pointed out in his comment above) is that the shared pointer is a global object, which means that on process exit, its destructor won't be called until after main() has returned, at which point (I'm speculating but pretty confident) various data structures that the QCoreApplication object's destructor might access have already been torn down and disposed of, and so you get a crash when it tries to access them. (For example, the argv pointer that you pass to the QCoreApplication constructor might not be valid anymore at the time that the QCoreApplication destructor runs)

However, I have no way to destroy the QCoreApplication unless I force the user to call some finalize() method.

One thing you could try is to register a callback function with atexit() that deletes the QCoreApplication object. Hopefully the atexit() callback will get called early enough in the shutdown sequence that this would get you the behavior you want. (Or if all else fails you could just let the QCoreApplication object leak; since the process is about to be destroyed anyway I don't think that would be particularly harmful to do)

Jeremy Friesner
  • 70,199
  • 15
  • 131
  • 234
  • Very clear explanation, thank you. From the page you linked: _[...] can be used [...] to establish functions that are called when the shared library is unloaded._ While this seems to work for the basic example in my question, it does not for the complete case on python bindings. I read [here](https://stackoverflow.com/a/13586487/1229582) that the call sequence should be defined, but I think (as of C++11) [this](http://en.cppreference.com/w/cpp/utility/program/atexit) applies: _The functions may be called concurrently with the destruction of the objects with static storage duration..._ – matpen Jul 30 '17 at 05:12
  • After more testing I cannot find better solution than leaking the `QCoreApplication` object. Accepting the answer, since it provides a very plausible explanation. – matpen Aug 13 '17 at 14:05
  • More precisely, the QCoreApplication constructor accesses coreappdata() which is another global object -- and that one tends to get deleted first. So destroying QCoreApplication from a global object is a big no-no, it'll crash when trying to access coreappdata(). – David Faure Aug 25 '23 at 15:05