Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ProviderPrivate desctructor is unsafe #11

Open
vekkuli opened this issue Mar 3, 2019 · 1 comment
Open

ProviderPrivate desctructor is unsafe #11

vekkuli opened this issue Mar 3, 2019 · 1 comment

Comments

@vekkuli
Copy link

vekkuli commented Mar 3, 2019

The Provider/ProviderPrivate class destructor causes a crash in certain cases. See the destructor below:

ProviderPrivate::~ProviderPrivate()
{
    if (confirmed) {
        farewell();
    }
}

The farewell() function then proceeds to use the server member variable. This causes a crash if the objects are not deleted in correct order. The example/doc code

QMdnsEngine::Server server;
QMdnsEngine::Hostname hostname(&server);
QMdnsEngine::Provider provider(&server, &hostname);

is safe because the destructors of local objects are called in the reverse order of their constructors (~Provider() --> ~Hostname() --> ~Server()). The following, perhaps as surprise to many however, is not:

QMdnsEngine::Server* mServer = new QMdnsEngine::Server(this);
QMdnsEngine::Hostname* mHostname = new QMdnsEngine::Hostname(mServer, this);
QMdnsEngine::Provider* mProvider = new QMdnsEngine::Provider(mServer, mHostname, this);

because the QObject children are deleted in a different order (~Server() --> ~Hostname() --> ~Provider()).

The problem is trivial to go around by forcing the deletion order but I think proper Qt integration and QObject conformance would require supporting the natural QObject child object deletion order as well.

@KonstantinRitt
Copy link
Contributor

#21 seems to be related

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants