Signals from other threads are not delivered directly, but via Qt’s event system. So it may be that the object has been destroyed already. Instead of calling deleted directly on the object (delete xyz) you could schedule the destruction using Qt’s event system by calling xyz->deleteLater(). It’s just a guess, I did not test it.

Volker wrote:

Instead of calling deleted directly on the object (delete xyz) you could schedule the destruction using Qt’s event system by calling xyz->deleteLater(). It’s just a guess, I did not test it.

This might solve the problem, but it is not guaranteed. If an object from another thread issues an async signal after deleteLater call, it will be put to the event queue after the delete call. So same issue.

You can try to catch the closing action checking

Another way is capturing the QEvent::close() on your QCoreApplication.

At application closeDown the form is most probably already destroyed.

Using deleteLater() makes sure that the object is only deleted at the next run of the event loop – this usually happens when the slots directly connected to a signal have finished their work (unless you call processEvents manually). Every pending event directed to the object to be deleted is nuked in that case.

That’s true @Volker. Thanks for your tip ^^

By the way, i remember a signal named onClose but i cant find at documentation. But im sure i used it some time ago.

Nevermind, was a custom signal i made capturing the QEvent::close. :P

That is a great point Volker. Thank you all for your input. I will be testing this today.