crashing Qt through a QObject's dtor

[René J.V. Bertin]

On Tuesday January 06 2015 13:07:02 David Faure wrote:

> It's wrong because it's fixing the symptom (null d pointer) instead of fixing 
> the cause (using an action that was already deleted).

In an absolute sense you're right. But if this happens because of an API/runtime marriage that's (almost) impossible to get right, shouldn't there be protections in place for when an unforeseen thing happens?
When I discussed this with an Apple dev maintaining XQuartz, his position was that Qt should have been built with an ObjC retain/release system instead of allowing `delete` because it's so much more robust in asynchronous (UI) event systems.
In Ian's words (whose young days are a tad before mine):
> Not at all, IMHO.  In my young day it used to be known as "defensive
> programming"…


> My recommendation: run the app in valgrind.

I doubt that will help. At most it will tell me what the crash already told us, or (an even longer shot I think), it might indicate that the same issue does exist on Linux too but without normally triggering an exception. I don't see how it can tell which object shouldn't have been deleted, because the deletion action itself completes fine.

The only way I see to debug this is to identify the deleted object. I've been trying that, but I run into the weird situation where the stock QAction::isEnabled crashes (in the 1st call after clicking away the dialog), but not when I change it to

bool QAction::isEnabled() const
{
    Q_D(const QAction);
    //return d->enabled;
    if (d) {
        return d->enabled;
    }
    else {
        return d->enabled;
    }
}

the optimiser is clever enough to remove the if so I can only break on the 1st return statement and not on the if line, but still something is different enough for the illegal access to be prevented ...
Same thing happens when I take the stock isEnabled function (= only the out-commented line and not the if/else expr) and compile qaction.cpp with -O0 -g ...

R.