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

List:       kopete-devel
Subject:    Re: [Kopete-devel] 0.6.1a MSN crash backtrace + debug
From:       Jason Keirstead <jason () keirstead ! org>
Date:       2003-03-05 0:46:08
[Download RAW message or body]

On March 4, 2003 08:12 pm, Will Stephenson wrote:
> What I think happens is
>
> * There is a QMap containing KopeteContactLVIs in the chatview, used for
> the dockable list of contacts in the chat
> * These LVIs are connected to the displayNameChanged signal that Contacts
> emit, and call sort on their parent listview after the name changes
> * The LVIs persist after the deletion of their chatview.  When they get the
> signal and try to sort the deleted listview, we crash.

No, this is supposed to be impossible with QT. All QListViewItems have the parent
QListView, which has the chatview itself as a parent. When the chatview is
destroyed, so is the listview, and so are all the listview items. At least that is
how it is supposed to work.

> Also Jason, I know you've erased all knowledge of older versions of Kopete,
> but could you undergo hypnosis to see if there's any way the QMap
> ChatView::memberContactMap could cause KopeteContactLVIs to hang around
> after the rest of the chatview is gone?  I note that QMap is value based
> and that one holds KopeteContactLVI *, could that have any effect?

It shouldn't have any effect, because as said above, all the LVI items should
be deleted when their parent is.

This part of the code has certainly not changed since 0.6, so it should be
easy to duplicate using HEAD. Maybe valgrind can help.

-- 
Jason Keirstead, BCS
http://www.keirstead.org
_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]