[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