[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    KFileItemActions - why does it remember the actions it created, and deletes them?
From:       Frank Reininghaus <frank78ac () googlemail ! com>
Date:       2013-12-12 17:38:23
Message-ID: CAFoZWWhV3DjM45bOP4_LYwnTw-m7AzQPyL5Rkh1bnD6juZbUMg () mail ! gmail ! com
[Download RAW message or body]

Hi David,

there is this crash in the destructor of KFileItemActions:

https://bugs.kde.org/show_bug.cgi?id=328638

I've seen this backtrace several times in other reports.

It seems that the following happens:


1. In the openItemContextMenu() member of DolphinContextMenu, which
inherits KMenu, we create a KFileItemActions instance on the stack,
and use it to add actions to "this". The actions thus become children
of "this".

2. We call this->exec(), which runs a nested event loop.

3. For unknown reasons, "this" is deleted inside this nested event
loop, and its children, in particular the actions created by the
KFileItemActions instance, are deleted as well.

4. We return from the nested event loop, and then the destructor of
KFIleItemActions calls

qDeleteAll(m_ownActions);

Since m_ownActions now contains dangling pointers, we get a crash.


The thing that I don't quite understand is: why does KFileItemActions
delete the actions at all? In all reasonable use cases, these actions
become the child of a menu, which can care of the deletion, right? If
that assumption is correct: can we maybe remove the m_ownActions
member altogether? It seems that it's only ever used to append()
actions, and to delete them in the destructor.

If I've overlooked something, and we really have to keep m_ownActions
and delete the actions in the destructor, maybe we could make it a
QObjectCleanupHandler? This would at least prevent the "delete
dangling pointer" problem.

Thanks and best regards,
Frank
[prev in list] [next in list] [prev in thread] [next in thread]