[Interest] QCoreApplication::arguments(): getting the application name safely during global destruction
René J.V. Bertin
rjvbertin at gmail.com
Tue Jan 21 11:54:30 CET 2020
Thanks for the answers; I almost missed them because of GMane changes.
> Sorry, it's a bug in the application code.
I was beginning to think as much.
> QCoreApplication keep s a reference to argc. Since main() has exited, the
> reference is now dangling
I suppose this depends on the runtime, but at some point the memory will indeed be freed.
> this reason and many others,) QCoreApplication should have been destroyed
> before main() returned.
Hmmm, this happened in a style plugin called from the MuseScore application which allocates the application instance using `new`; I think I triggered this codepath where main() indeed exits without deallocating the instance first:
```
if (MScore::noGui) {
#ifdef Q_OS_MAC
// see issue #28706: Hangup in converter mode with MusicXML source
qApp->processEvents();
#endif
exit(processNonGui(argv) ? 0 : EXIT_FAILURE);
}
else {
```
So you're suggesting I should report this as an issue in their code?
BTW, does qApp get reset to NULL/nullptr when the QCoreApplication instance is destroyed, IOW, is testing qApp safe even during global destruction (under normal circumstances)?
> And if your code is a plugin, you
> must also deal with the case where the application modifies argv or passes
> something completely different to QCoreApplication.
Theoretically I should, but in practice this code is just to special-case specific applications, and for now we can do that using the argv[0] value at the time the plugin is loaded (because the apps needing the special-casing don't pull tricks in this department).
R.
More information about the Interest
mailing list