KSharedPtr breakage

[Hamish Rodda]

Hi,

Frerich's new KSharedPtr was committed yesterday, and there's (at least) one 
major side effect that is making current kdelibs head unusable (kbuildsycoca 
crashes to start).

The problem is that the reference counting has moved from the object itself 
into the shared pointer.  What this means is that if two shared pointers are 
created using an intermediary dumb pointer, two separate reference counts are 
created.  Then, when one of those shared pointers goes away, it deletes the 
object, leaving the other shared pointer with a stale pointer.

This is demonstrated in the following code:
#include "ksharedptr.h"

#include <QString>

class Test : public KShared
{
  public:
    Test(const QString& s) : string(s) {};

    QString string;
};

int main()
{
  KSharedPtr<Test> u = new Test( "Foo" );

  Test* dumbIntermediate = u.data();
  {
    KSharedPtr<Test> x = dumbIntermediate;
  }

  Q_ASSERT( u->string == "Foo" );
}

The assert causes an invalid read, because x has deleted the Test instance 
referred to by u when it goes out of scope.

This practice is commonplace throughout at least KSycocaEntry.  I tried to 
port it over to 100% shared pointers, but encountered a problem with 
covariant returns - KSharedPtr can't be used (in its current form) in a 
covariant return with different class types, and you can't assign from 
KSharedPtr of different class types either (only via the dumb pointer method 
above, hence it's no good).  So, KSycocaFactory::create() won't compile in 
subclasses.  I can't think of a great solution here.

For now, i'm planning to comment out the delete line in KSharedPtr (i know, 
not good) and keep working on kate ;) but if anyone is interested in how far 
i got, my patch is at 
http://members.optusnet.com.au/~hamishrodda/kdelibs-ksharedptr-20051023.patch

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051023/ff616d92/attachment.sig>