QGraphicsView::paintEvent crashes

Jan-Willem

Yes, but does setupDiagram() check if the Diagram item is indeed deleted?

SGaist

Hi,

QGraphicsObject being a QObject, you should rather call deleteLater on it. That way the event loop handle its deletion.

ModelTech

@Jan-Willem
No, how can I do that?

@SGaist
Using deleteLater does not make the crash disappear...

SGaist

Where are you calling that code from ?

ModelTech

The code I gave is called from the QWidget that contains the QGraphicsScene Scene, which has this QGraphicsObject Diagram as item. I have a destructor of the Widget that deletes Diagram, but perhaps that is not needed as it is a QObject?

Edit: removing my destructor does not change a thing wrt the crashes...

What are typical situations to use deleteLater instead of delete?

kshegunov

@ModelTech said in QGraphicsView::paintEvent crashes:

What are typical situations to use deleteLater instead of delete?

In almost all situations it's preferred when dealing with QObject instances.

On certain occasions, my complete application crashes on Linux and the trace given in the debugger does not show any of my code but only Qt code and the last human readable message is on QGraphicsView::paintEvent, see below.

Eh, your stack trace is full of holes, sadly. Are you sure you're getting it from a debug build of your application?

ModelTech

@kshegunov
Thanks for the clarification on the deleteLater, I will change my code accordingly.

The holes are indeed what I get from the debugger, showing assembly code when inspecting...

kshegunov

@ModelTech said in QGraphicsView::paintEvent crashes:

The holes are indeed what I get from the debugger, showing assembly code when inspecting...

Which just strengthens my suspicion you're debugging a release build, could you please check that?

ModelTech

I am using a debug build, but I have investigated changing it to a release build, just to see the difference in error message. Conclusion: there is no difference...

The fact that changing the build type was effective is seen from a difference in one warning that I get during compilation for the release build that I do not get for a debug build (it is about a variable that may be uninitialized, which in this case cannot occur in practice).

SGaist

Why can it not occur in practice ?

ModelTech

@SGaist Well, the considered code looks currently like this (where the warning is on variable Label). Perhaps I should change the third if into an else to avoid the warning. Anyway, changing this does not solve the crashing problem (I tried) as it is in a totally different/unrelated part of my code.

if (Specification->isCSDFActor() || Specification->isDetector()) {
    QLabel *Label;
    if (Specification->isCSDFActor())
        Label = new QLabel(tr("<strong>Phases</strong>"), this);
    if (Specification->isDetector())
        Label = new QLabel(tr("<strong>SubScenarios</strong>"), this);
    QVBoxLayout *SubScenarioLayout = new QVBoxLayout;
    SubScenarioLayout->addWidget(Label);
}

SGaist

With the code at hand then indeed, it should not happen.

To be on the clean and safe side, I'd rather write QLabel *Label = Q_NULLPTR; or QLabel *Label = nullptr;

kshegunov

I realized that it may be system calls that are made in those stack holes. The most often crash I've encountered in the event loops is when an object is passed to Qt and it's subsequently deleted while events intended for it are still pending. I think you should check that this doesn't happen here..

ModelTech

Ok, that sounds like a scenario that could be the case here. Is there an easy way to check whether events are pending for an object? Is there a way to clear the buffer holding events for an object that I could perhaps call before using delete/deleteLater?