When exactly does QObject::deleteLater() actually delete?

[JonB]

@SGaist said in When exactly does QObject::deleteLater() actually delete?:

What about the python del statement ?

For the record: https://stackoverflow.com/a/39255472/489865

If you are writing something bulky, you should know that del does not delete the object, it just dereferences it. I.e. variable no longer refers to the place in memory where object data is stored. After that it still needs to be cleaned up by garbage collector in order for memory to be freed (that happens automatically).

In Python's reference-count and garbage-collect model, del is not really anything like C++ delete. All it does is decrement a count, e.g.

widget = QWidget()
something = widget
del widget

does not delete/destroy/free the QWidget!

[Gojir4]

@JonB Hi,

Documentation of QEventLoop::ProcessEventsFlag confirms that deleteLater() (DefferedDeleteEvent) is a special case.

QEventLoop::AllEvents:
All events. Note that DeferredDelete events are processed specially. See QObject::deleteLater() for more details.

But it looks like there is now way to really ensure that's object is destroyed.

[JonB]

@Gojir4
That is a good reference. The trouble is, I have already quoted from "See QObject::deleteLater() for more details." and (to me) that doesn't explain much better! :)

[JonB]

@VRonin said in When exactly does QObject::deleteLater() actually delete?:

First thing first. The right thing to do here is to reuse the dialog.
Crate it once, execute 1 cycle of the loop, reset its properties and use it again. Creating and deleting "hundreds (or even thousands)" is incredibly inefficient.

Just for the record (because I just know you're interested!). The reason I have to have this UI/dialog is purely to host a QWebEnginePage for printToPdf(). That requires the QWebEnginePage to do two things: the HTML has to be loaded, and then printToPdf() can be called after that (not before) to convert. As you might imagine, the continual recreation & disposal of the dialog we have been talking about is absolutely miniscule compared to these two activities (I think it actually takes longer to finish loading the HTML than to convert it to PDF!). So I could bust my whatevers trying to preserve the dialog as you said, but I think it will make zero difference to my timings, sadly :(

[JKSH]

@JonB said in When exactly does QObject::deleteLater() actually delete?:

The reason I have to have this UI/dialog is purely to host a QWebEnginePage for printToPdf(). That requires the QWebEnginePage to do two things: the HTML has to be loaded, and then printToPdf() can be called after that (not before) to convert.

There might be better tools for the job. See my post at https://forum.qt.io/topic/94330/generating-pdf-from-html-fast

As you might imagine, the continual recreation & disposal of the dialog we have been talking about is absolutely miniscule compared to these two activities (I think it actually takes longer to finish loading the HTML than to convert it to PDF!). So I could bust my whatevers trying to preserve the dialog as you said, but I think it will make zero difference to my timings, sadly :(

But your main problem right now is running out of memory, right? If @VRonin's QEventLoop trick doesn't work for whatever reason, re-using the dialog will stop you from getting memory-starved.

Another possible workaround: Don't convert all the documents in one large for-loop. Instead, at the end of each conversion, emit a signal or call QMetaObject::invokeMethod() (with Qt::QueuedConnection for both options) to trigger the next conversion. Then, let the function return to the main event loop. This allows QCoreApplication delete your dialog before starting the next conversion.

[JonB]

@JKSH
Again, thanks, and I've posted my reason to you in the other thread.

To recap: I have now discovered that if I do not use the "recommended" deleteLater() and instead use QDialog::destroy() the memory is freed immediately. I can now process my hundreds/thousands of letters without any memory/resources accumulating till the end, and my most immediate problem of "running the whole machine out of memory" has gone away.

I am still investigating how much that actual "dialog create-destroy" is costing. But even though I'm sure it's considerable compared to re-use, it appears that it's actual miniscule compared to loading of the new HTML each time and converting to PDF (it's actually more the HTML load than the PDF convert which costs, perhaps not surprisingly). So re-using the same dialog probably wouldn't save me that much. Now that I have dealt with the memory issue of the repeated dialog I'm in a much happier place!

[VRonin]

@JonB said in When exactly does QObject::deleteLater() actually delete?:

use QDialog::destroy()

Make sure you are not running into random segfaults due to some thing inside Qt calling a slot of your dialog using Qt::QueuedConnection (or equivalents)

[JonB]

@VRonin
Hmm. I don't know if I know how I would know this?! I don't do anything slot-wise. I create the dialog and get it to load HTML into QWebEnginePage + print to PDF, that finishes synchronously, only then do I destroy the dialog.

Does that satisfy you? Or, would you rather I use your earlier deleteLater() + QEventLoop? Would that be safer? I presume that wrt your QueuedConnection this would be just as much of an issue if one used C++ delete as my use of explicit destroy? Or are you saying that delete would deal with this any better than destroy?

[VRonin]

@JonB said in When exactly does QObject::deleteLater() actually delete?:

this would be just as much of an issue if one used C++ delete as my use of explicit destroy? Or are you saying that delete would deal with this any better than destroy?

It is an issue even in C++ using delete indeed, that's the reason why QObject::deleteLater exists

[JKSH]

@JonB said in When exactly does QObject::deleteLater() actually delete?:

I don't do anything slot-wise. I create the dialog and get it to load HTML into QWebEnginePage + print to PDF, that finishes synchronously, only then do I destroy the dialog.

If it's fully synchronous and no signals/events touch these objects, then I'd imagine you should be fine.

Just be aware this is a fragile setup -- put big warning comments for yourself (and anyone else who might inherit your code) not to add any event-driven features in this section, or else inexplicable crashes might start occurring.

Or are you saying that delete would deal with this any better than destroy?

Disclaimer: I have never called QWidget::destroy() directly.

To clarify @VRonin's last comment, delete and destroy() have the same brittleness: They introduce the risk of signals/events getting delivered to an object that has already been freed. But if you code carefully, you can create a perfectly functional program with delete/destroy().

When using deleteLater(), we don't have to worry about this risk and can add event-driven features with gay abandon. (In theory, at least. This user doesn't seem to be getting the protection promised by deleteLater(): https://forum.qt.io/topic/93786/events-after-object-destruction Granted, this was back in Qt 4.8.6 so hopefully it's fixed by now)