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.
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
