CODEWITHSUNDEEP
c++qtsegmentation-faultdestructor
AaronD
AaronD

Reputation: 523

Calling member->function(this); in Destructor causes Segfault

Here's the offending code:

class FullPage : public QWidget
{
    Q_OBJECT
public:
    explicit FullPage(const AppData* appdata, QWidget* parent = 0);
    virtual void     addIconWorking(IconWorking* temp);
    virtual void  removeIconWorking(IconWorking* temp);
    ...
}

class IconWorking : public QLabel
{
    Q_OBJECT
public:
    explicit IconWorking(FullPage* parent = 0);
    virtual ~IconWorking();
    ...
}

IconWorking::IconWorking(FullPage* parent) : QLabel(parent)
{
    ...
    parentPage = parent;
    parentPage->addIconWorking(this);
    ...
}

IconWorking::~IconWorking()
{
    parentPage->removeIconWorking(this); //segfault
    QMessageBox::information(0, "TODO", "Reminder Message");
}

What am I missing?

Update:

I added some test code per the comments to see if parentPage ever changes. It doesn't. I'm using a newly created variable that is assigned in the constructor and checked in the destructor.

The segfault message does not specify an address. It'd be nice if it did. Checking the pointers directly gives a non-zero value, both the original and the added test, so they're not null.

I also discovered that when I add some functionality, I get a new segfault in a completely unrelated location where it references the same FullPage instance that is passed in arguments all around the program.

Upvotes: 1

Views: 211

Answers (2)

AaronD
AaronD

Reputation: 523

Well, I discovered a different part of the project that would have been awkward with that structure, so I:

  • Made FullPage's QList public.
  • Did away with the member functions to add and remove.
  • Had IconWorking manipulate it directly since that's all that was happening anyway.

Somehow, that seemed to fix the segfaults in the destructor, but I got them instead on some class definitions themselves. (What!?!) So I rebuilt the project, and that was fixed too.

So I guess the moral of this story is that if it's doing something weird, try a complete rebuild. A change in one class might require another to be recompiled, even if the other source didn't actually change, and Qt Creator doesn't necessarily know that.

Upvotes: 0

Frank Osterfeld
Frank Osterfeld

Reputation: 25155

Assuming that ~IconWorking() gets called when it's parentPage is destroyed, as the parent-child relationship suggests:

When the parentPage object is destroyed, things happen in the following order:

  1. ~FullPage() is called on the parentPage instance. After that, parentPage isn't a valid FullPage object anymore!
  2. ~Widget() is called, leaving a QObject.
  3. ~QObject() is called, which deletes your IconWorking object (because of the parent-child relationship)
  4. ~IconWorking() is executed which calls FullPage::removeIconWorking() on parentPage, which, I assume, accesses FullPage-specific members which were already destroyed in step 1. (The object parentPage points to is at this point only a valid QObject, nothing else!)
  5. Crash

To make this approach work, ~FullPage() would have to delete the IconWorking objects manually, instead of relying on the QObject parent-child relationship.

Upvotes: 2

Related Questions