segfault in QSqlDatabase::database when used in the destructor of a static variable when closing the app

[JonB]

@KroMignon
Purely OOI (untested), doesn't this apply to something like QObject classes? Can you use, say, a QVector outside of Q...Application, or is even that not allowed?

[KroMignon]

@JonB said in segfault in QSqlDatabase::database when used in the destructor of a static variable when closing the app:

Purely OOI (untested), doesn't this apply to something like QObject classes? Can you use, say, a QVector outside of Q...Application, or is even that not allowed?

Especially QObject classes!
A good coding practice with Qt is to first create QCoreApplication/QGuiApplication/QApplication at beginning of main(), in fact you don't really have to destroy it.

int main(int argc, char *argv[])
{
    QCoreApplication app(argc, argv);
    QCoreApplication::setApplicationName("...");
    QCoreApplication::setOrganizationName("...");
    QCoreApplication::setApplicationVersion("1.0.0");

    // continue initialization
    ...

    // start main loop and wait application end
    return app.exec();
}

[mbruel]

@JonB said in segfault in QSqlDatabase::database when used in the destructor of a static variable when closing the app:

I guess it's taken you shouldn't try to use most things Qt after Q...Application is destroyed. Like you could try to still use a QWidget, but I wouldn't recommend it....

well for QObject that uses the event loop definitely but QSqlDatabase doesn't seem to be a QObject...
and in general I obviously don't do this kind of things but using a static singleton as the Main app that would do some work on Database on its destructor could really happen... I guess in that case it should own the QApplication and delete it as the latest. On the project I'm working on it is not the case, the QApplication is defined in the main.cpp.

@JonB said in segfault in QSqlDatabase::database when used in the destructor of a static variable when closing the app:

Purely OOI (untested), doesn't this apply to something like QObject classes? Can you use, say, a QVector outside of Q...Application, or is even that not allowed?

I believe you could use QVector and other Qt objects without a QApplication. I didn't test but I don't see why not... as long as they don't use the event loop...

@KroMignon said in segfault in QSqlDatabase::database when used in the destructor of a static variable when closing the app:

A good coding practice with Qt is to first create QCoreApplication/QGuiApplication/QApplication at beginning of main(), in fact you don't really have to destroy it.

well in general yes... for small programs. but it is quite common to rather embed the QCoreApplication/QGuiApplication/QApplication in the Object representing your application, especially if you parse the command line and can either launch a GUI or stay PURE command line (only QCoreApplication)
you can find an example of such main.cpp here where my app derives from CmdOrGuiApp.

[Christian Ehrlicher]

Don't use global static singletons.

[KroMignon]

@mbruel said in segfault in QSqlDatabase::database when used in the destructor of a static variable when closing the app:

well in general yes... for small programs. but it is quite common to rather embed the QCoreApplication/QGuiApplication/QApplication in the Object representing your application, especially if you parse the command line and can either launch a GUI or stay PURE command line (only QCoreApplication)
you can find an example of such main.cpp here where my app derives from CmdOrGuiApp.

No this is not common!
You never have to use QObject before creating QCoreApplication/QGuiApplication/QApplication.
Of course, sometimes you want to parse command line before creating one of those, but when doing this, you do not use QObject based classes but only C++ standard functions like this example taken from Qt documentation:

QCoreApplication* createApplication(int &argc, char *argv[])
{
    for (int i = 1; i < argc; ++i) {
        if (!qstrcmp(argv[i], "-no-gui"))
            return new QCoreApplication(argc, argv);
    }
    return new QApplication(argc, argv);
}

int main(int argc, char* argv[])
{
    QScopedPointer<QCoreApplication> app(createApplication(argc, argv));

    if (qobject_cast<QApplication *>(app.data())) {
       // start GUI version...
    } else {
       // start non-GUI version...
    }

    return app->exec();
}

[mbruel]

@Christian-Ehrlicher said in segfault in QSqlDatabase::database when used in the destructor of a static variable when closing the app:

Don't use global static singletons.

A Singleton class like this is quite useful and there is no issue with it as you can connect QCoreApplication::aboutToQuit to the deletion of its instance if needed (so before the destruction of the QCoreApplication).
It's a matter of taste, personally I find it really convenient to be able to use a singleton using MyObject::instance() rather than having to provide an handle to it (either in function calls or in the constructor and storing it as a member)

@KroMignon said in segfault in QSqlDatabase::database when used in the destructor of a static variable when closing the app:

You never have to use QObject before creating QCoreApplication/QGuiApplication/QApplication.
Of course, sometimes you want to parse command line before creating one of those, but when doing this, you do not use QObject based classes but only C++ standard functions like this example taken from Qt documentation

well of course you don't have to use a QObject, but who says you shouldn't if it is convenient for you?...
If you look QCoreApplication documentation, its main goal is to provide an event loop for your application (main thread).
There is no issue creating QObject before or without it as long as you don't uses events, is there?
I've done few softwares where I create my main QObject that will instantiate the QCoreApplication and it's working just fine. This main object is then able to use the event queue...
I don't understand why you would say we shouldn't do that, what is the reason?
Some people even inherit from QCoreApplication but for what I read few years ago, it was more advised to initiate it (and own it) than subclassing (this allowing to be able to choose which instance you need depending on whatever condition)

[KroMignon]

@mbruel said in segfault in QSqlDatabase::database when used in the destructor of a static variable when closing the app:

I don't understand why you would say we shouldn't do that, what is the reason?

I am only sharing my experience with you, if you think it is not relevant to you, never mind. This is not a problem for me.

And if you look to QCoreApplication documentation, you will find this:

In general, we recommend that you create a QCoreApplication, QGuiApplication or a QApplication object in your main() function as early as possible. exec() will not return until the event loop exits; e.g., when quit() is called.

The reason is to avoid having to find strange bugs in your application, like qDebug() not working (which I had to find some years ago).

[mbruel]

@KroMignon well you were quite affirmative in your replies...
I care of other people experiences and opinions but we're also here to understand what's possible, what's advised, what's not advised and most of all what's not possible preferably with a concrete explanation

[KroMignon]

@mbruel said in segfault in QSqlDatabase::database when used in the destructor of a static variable when closing the app:

well you were quite affirmative in your replies...
I care of other people experiences and opinions but we're also here to understand what's possible, what's advised, what's not advised and most of all what's not possible preferably with a concrete explanation

Sorry about that, I am a french guy living in Germany and writing in english... Sometimes there are too many languages in my head and I don't find the right words.
I will try to take more care about my writing to be less directive.

But this was a really hard bug to find, only because I create QCoreApplication too late in my main()

[mbruel]

@KroMignon
pas de problèmes ;)
yeah it's defo something unusual that can bring unexpected issues and/or crashes...