QGraphicsView::paintEvent crashes

I have a QWidget that contains a QGraphicsScene with a single QGraphicsObject. In several situations I need to replace the QGraphicsObject by a new one, and when doing so I also change the sceneRect of the QGraphicsScene (based on the boundingRect of the QGraphicsObject). 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.

On MacOS and Windows (MinGW) there is no crash when replacing the QGraphicsObject, but a crash occurs at closing/destroying the complete Widget.

I have not reimplemented this paintEvent method in any way, so I guess I am doing something else wrong. The strange thing is however that in many situations it does work fine. Here is the code that I use to replace the QGraphicsObject, which is called Diagram:

void QGraphicsScene::removeItem(QGraphicsItem *item)
Removes the item item and all its children from the scene. The ownership of item is passed on to the caller (i.e., QGraphicsScene will no longer delete item when destroyed).

Could it be that while the item is removed from the scene while it is not deleted?

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...

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?

Even if we accept, as the basic tenet of true democracy, that one moron is equal to one genius, is it necessary to go a further step and hold that two morons are better than one genius?

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 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.

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..

Even if we accept, as the basic tenet of true democracy, that one moron is equal to one genius, is it necessary to go a further step and hold that two morons are better than one genius?

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?