Re: [Interest] How to properly delete qApp?

[Nuno Santos]

Nikos,

Thanks for your reply. 

The problems is that host application hangs forever if I don’t delete it and 
crashes if I delete it. I’m in a kind of dead end.

Any ideas?

Thanks

Nuno

> On 16 Mar 2016, at 14:07, Nikos Chantziaras  wrote:
> 
> On 16/03/16 14:01, Till Oliver Knoll wrote:
>> I don't think you're supposed to delete qApp
> 
> Actually you do need to delete it. Most people don't because after 
> qApp->exec() returns, the program ends anyway. But if you want to have 0 
> leaks, you need to delete your QApplication instance.
> 
> Usually you don't delete qApp directly, but just your instance, but that's 
> the same thing, really:
> 
>  int main(int argc, char** argv)
>  {
>  QApplication app = new QApplication(/* ... */);
>  app->exec();
>  delete app;
>  // or:
>  // delete qApp;
>  // which does the same thing.
>  }
> 
> In normal applications, like the above, deleting it is redundant. You're 
> exiting the process, so the environment is going to clean your memory anyway. 
> It's still a memory leak, if you're pedantic about it.
> 
> If you're using QApplication in a plugin, deleting qApp is actually 
> mandatory, otherwise you're leaking the qApp instance when the plugin 
> unloads; no one else is going to delete it for you.
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to properly delete qApp?

[Jan Kundrát]

On Wednesday, 16 March 2016 15:07:30 CET, Nikos Chantziaras wrote:

  QApplication app = new QApplication(/* ... */);
  app->exec();
  delete app;


There's no point to use heap allocation in this context. You can simply 
create a QApplication instance on stack in your main.


Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to properly delete qApp?

[Nikos Chantziaras]

On 16/03/16 14:01, Till Oliver Knoll wrote:

I don't think you're supposed to delete qApp


Actually you do need to delete it. Most people don't because after 
qApp->exec() returns, the program ends anyway. But if you want to have 0 
leaks, you need to delete your QApplication instance.


Usually you don't delete qApp directly, but just your instance, but 
that's the same thing, really:


  int main(int argc, char** argv)
  {
  QApplication app = new QApplication(/* ... */);
  app->exec();
  delete app;
  // or:
  // delete qApp;
  // which does the same thing.
  }

In normal applications, like the above, deleting it is redundant. You're 
exiting the process, so the environment is going to clean your memory 
anyway. It's still a memory leak, if you're pedantic about it.


If you're using QApplication in a plugin, deleting qApp is actually 
mandatory, otherwise you're leaking the qApp instance when the plugin 
unloads; no one else is going to delete it for you.


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to properly delete qApp?

[Till Oliver Knoll]

> Am 16.03.2016 um 13:01 schrieb Till Oliver Knoll 
> :
> 
> 
> ...
> 
> Oh, and somewhat related: just make double-sure on OS X that your Qt plugin - 
> specifically all GUI and paint operations - happen in the /main/ thread of 
> the host application (if that's possible at all, i.e. you control/own the 
> host app, too). It won't work otherwise (unless you hack your own Cocoa event 
> queue for the host application, and even then you're in a mine field whenever 
> calling other Cocoa APIs... just google for "Qt event queue thread OS X" or 
> the like...)

Just to clarify: this is not a limitation of the Qt implementation on OS X 
(iOS), but really a limitation (by design) of the underlying Cocoa.

And yes, having a Qt event loop running in a thread other than the "main" 
thread /does/ work on Windows and Linux (possibly/likely other Unix) - just not 
on OS X/Cocoa.

Here's a link for starters:

  
http://stackoverflow.com/questions/22289423/how-to-avoid-qt-app-exec-blocking-main-thread

Cheers,
  Oliver___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to properly delete qApp?

[Till Oliver Knoll]

> Am 16.03.2016 um 11:51 schrieb Nuno Santos :
> 
> Hi,
> 
> My application is targeted to run as a software plugin inside another third 
> party application. When a instance of my plugin is instanciated I check if 
> qApp exists. If so, I will use that pointer, otherwise I will reuse the 
> pointer. I also increment a counter to know how many instances of my 
> plugin are active. When the plugin is deleted I check the counter. If it gets 
> to zero I will delete qApp.

I don't think you're supposed to delete qApp (btw which is just a convenience 
macro for QCoreApplication::instance, since Qt 5.x I think).

The way to end a Qt application is to tell it to QCoreApplication::exit which 
will then leave the (existing) Qt event loop with the given return code.

GUI applications usually QGuiApplicatiob::quitOnLastWindowClosed.

Once the Qt event queue is left Qt does all cleanup (or doesn't: there's quite 
a bit of discussions every then and when about memory leaks when Qt apps quit: 
but since they quit anyway those "global left-overs" are considered "to be 
dealt with by the OS - there are arguments for and against this practise...).

In any case, you shouldn't interfere with the Qt cleanup. Specifically the 
global Qt app instance "belongs to Qt".


Why do you query the state of qApp anyway? Do you have multiple instances of 
your Qt plugin (in a possibly non-Qt host application) and want to prevent the 
launch of the Qt event queue multiple times?

Oh, and somewhat related: just make double-sure on OS X that your Qt plugin - 
specifically all GUI and paint operations - happen in the /main/ thread of the 
host application (if that's possible at all, i.e. you control/own the host app, 
too). It won't work otherwise (unless you hack your own Cocoa event queue for 
the host application, and even then you're in a mine field whenever calling 
other Cocoa APIs... just google for "Qt event queue thread OS X" or the like...)

Cheers,
  Oliver

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to properly delete qApp?

[Nikos Chantziaras]

I doubt you can get out of this issue. QApplication wants to be in 
control of the main loop, and it wants to do so from the main thread.


Failing that, you'd need to integrate the host application's event loop 
into Qt's event loop, and still have a way to cal QApplication::exec() 
on the main thread. If your host application does not allow for those 
two things, I'd say there's nothing you can do.



On 16/03/16 17:42, Nuno Santos wrote:

Nikos,

Thanks for your reply.

The problems is that host application hangs forever if I don’t delete it
and crashes if I delete it. I’m in a kind of dead end.

Any ideas?

Thanks

Nuno


On 16 Mar 2016, at 14:07, Nikos Chantziaras > wrote:

On 16/03/16 14:01, Till Oliver Knoll wrote:

I don't think you're supposed to delete qApp


Actually you do need to delete it. Most people don't because after
qApp->exec() returns, the program ends anyway. But if you want to have
0 leaks, you need to delete your QApplication instance.

Usually you don't delete qApp directly, but just your instance, but
that's the same thing, really:

 int main(int argc, char** argv)
 {
 QApplication app = new QApplication(/* ... */);
 app->exec();
 delete app;
 // or:
 // delete qApp;
 // which does the same thing.
 }

In normal applications, like the above, deleting it is redundant.
You're exiting the process, so the environment is going to clean your
memory anyway. It's still a memory leak, if you're pedantic about it.

If you're using QApplication in a plugin, deleting qApp is actually
mandatory, otherwise you're leaking the qApp instance when the plugin
unloads; no one else is going to delete it for you.

___
Interest mailing list
Interest@qt-project.org 
http://lists.qt-project.org/mailman/listinfo/interest







___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to properly delete qApp?

[Nikos Chantziaras]

On 16/03/16 16:12, Jan Kundrát wrote:

On Wednesday, 16 March 2016 15:07:30 CET, Nikos Chantziaras wrote:

  QApplication app = new QApplication(/* ... */);
  app->exec();
  delete app;


There's no point to use heap allocation in this context. You can simply
create a QApplication instance on stack in your main.


Indeed. But I needed an example with a pointer. If you use a stack 
object, you'd obviously never have the problem of deleting it to begin 
with :-)


The point is, you *do* delete qApp *if* it's on the heap, but most 
people who do have qApp on the heap don't bother with delete, since the 
process exits anyway. Since in the OP's case the process doesn't exit, 
qApp should actually be deleted.


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] How to properly delete qApp?

[Nuno Santos]

Hi,

My application is targeted to run as a software plugin inside another 
third party application. When a instance of my plugin is instanciated I 
check if qApp exists. If so, I will use that pointer, otherwise I will 
reuse the pointer. I also increment a counter to know how many instances 
of my plugin are active. When the plugin is deleted I check the counter. 
If it gets to zero I will delete qApp.


The problem is that  I'm having a different behaviour across platforms. 
On OSX I don't even need to delete qApp, everything works alright. On 
Windows, if I don't delete the qApp, the host hangs, seems like a dead 
lock, so I need to force delete it and this is what I am doing:


_app->processEvents(QEventLoop::AllEvents, 1000);
_app->quit();
delete _app;
_app = 0;

This way, the host is able to close and exit but the return code is not 
zero, it is basically crashing but no error window pops up. If I don't 
call delete _app, the host hangs and it is not able to exit.


It is important to refer that I'm using a static and namespaced build of 
Qt and that I'm calling a new Windows thread to call qApp exec.


The thread body has two modes. Why? Because when I call _app->exec() it 
immediatelly returns saying that it must be called from main thread, 
however things continue to happen, Qml works, QObjects works, apparently 
at least! The approach works also, not apparent problems, but the thread 
doesn't return.


#ifdef Q_OS_WIN
unsigned int id;
Qt::HANDLE h = (Qt::HANDLE) _beginthreadex(NULL, 0, threadInit, this, 0, 
);

#endif

#ifdef Q_OS_WIN
unsigned int __stdcall threadInit(void *args)
{
qDebug() << "--Qt Init Thread";
IVst *plugin = (IVst*)args;

#if 1
while(plugin->_running)
plugin->_app->processEvents();
#else
plugin->_app->exec();
#endif

qDebug() << "--Thread done";
return 0;
}

So far on OSX I was not even deleting the app and it worked without issues.

Does anyone has a clue of what is going on?

Thanks,

Regards,

Nuno
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest