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

List:       kmail-devel
Subject:    Re: [PATCH] Re: Obscure but reproducable crash.
From:       Don Sanders <sanders () kde ! org>
Date:       2002-06-30 10:30:11
[Download RAW message or body]

As my diff has a decent chance of preventing unforseen problems like 
the one Waldo produced I committed it.

Actually it won't prevent a crash when kmreaderwin.cpp is compiled 
debug because of the QASSERTs, since I would like to find any bugs 
that exist. But if someone has a problem with that feel free to 
replace the QASSERTs with a kDebug.

I've also thought about ref counting KMMessage some more. I'm leaning 
towards it being a good idea. And even a realistic idea if it can be 
implemented in a non-dangerous incremental way.

The obvious incremental way is to just create ref counted KMMessage 
KMMessageRef and add a KMFolder::getMessageRef method. Then use these 
in a few places, say just in KMReaderWin to begin with. But if that 
works slowing replacing KMFolder::getMsg with getMessageRef until 
eventually getMsg and unGetMsg can be removed. This will mean 
KMMsgList will only store KMMsgBases.

The obvious problem with this approach is that it leads to extra 
memory being used. For instance I just noticed 
KMMainWin::updateMessageActions calls getMsg. Which would lead to two 
KMMessage's being created when a message is selected. I'll try to 
prevent that from happening.

I'm a bit worried porting something like KMComposeWin over to 
KMMessageRef will require a large jump instead of an incremental one 
but I'll do some exploratory programming and see how bad it will be. 
I definitely don't want to make changes that will introduce 
unstability.

Eventually a KMMessageRef should do just the opposite and make it 
easier to avoid memory allocation mistakes concerning KMMessage that 
lead to crashes.

On Monday 24 June 2002 07:04, Ingo Klöcker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 22 June 2002 15:49, Don Sanders wrote:
> > Using refcounting wouldn't solve this problem completely as
> > there's the problem of the seperate view actions depending on the
> > current item in kmheaders.
>
> And therefore this uglyness has to be removed.

Yes I'll have a look at this too. But this should be a comparatively 
minor change.

Don.

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]