ref-count assertion in cppu::OWeakObject ...

[Michael Meeks]

So,

	I was wondering reading:

	https://bugs.freedesktop.org/show_bug.cgi?id=53154#c5

	"...either memory corruption or a ref-counted UNO object
	forcefully being deleted before its ref-count is zero"

	It seemed to me that we could catch the latter case and avoid it
causing problems later, at least for people using the standard classes.
So I was thinking of:

--- a/cppuhelper/source/weak.cxx
+++ b/cppuhelper/source/weak.cxx
@@ -235,6 +235,9 @@ void OWeakObject::disposeWeakConnectionPoint()
 
 OWeakObject::~OWeakObject() SAL_THROW( (RuntimeException) )
 {
+    fprintf( stderr, "~OWeakObject: %d\n", (int)m_refCount );
+    if (m_refCount != 0)
+        abort(); // memory corruption coming ...
 }
 
 // XWeak

	Which kills ~1200 objects until we get to:

...
  1222	~OWeakObject: 0
  1223	~OWeakObject: 1

	With a trace from the (already somewhat suspicious lifecycle-wise IMHO)
package/ code:

#1  0xb7c8e1d5 in __GI_abort () at abort.c:93
#2  0xb7a7e66d in cppu::OWeakObject::~OWeakObject (this=0xb07a79b0, __in_chrg=<optimized out>)
    at /data/opt/libreoffice/master/cppuhelper/source/weak.cxx:239
#3  0xb0478280 in cppu::WeakImplHelper5<com::sun::star::packages::zip::XZipFileAccess, com::sun::star::container::XNameAccess, com::sun::star::lang::XInitialization, com::sun::star::lang::XComponent, com::sun::star::lang::XServiceInfo>::~WeakImplHelper5 (this=0xb07a79b0, 
    __in_chrg=<optimized out>) at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/cppuhelper/implbase5.hxx:107
#4  0xb0476a69 in OZipFileAccess::~OZipFileAccess (this=0xb07a79b0, __in_chrg=<optimized out>)
    at /data/opt/libreoffice/master/package/source/zippackage/zipfileaccess.cxx:53
#5  0xb0476af6 in OZipFileAccess::~OZipFileAccess (this=0xb07a79b0, __in_chrg=<optimized out>)
    at /data/opt/libreoffice/master/package/source/zippackage/zipfileaccess.cxx:66
#6  0xb7a7e9b5 in release (this=0xb07a79b0) at /data/opt/libreoffice/master/cppuhelper/source/weak.cxx:213
#7  cppu::OWeakObject::release (this=0xb07a79b0) at /data/opt/libreoffice/master/cppuhelper/source/weak.cxx:206
#8  0xb04781ee in cppu::WeakImplHelper5<com::sun::star::packages::zip::XZipFileAccess, com::sun::star::container::XNameAccess, com::sun::star::lang::XInitialization, com::sun::star::lang::XComponent, com::sun::star::lang::XServiceInfo>::release (this=0xb07a79b0)
    at /data/opt/libreoffice/master/solver/unxlngi6.pro/inc/cppuhelper/implbase5.hxx:119
...

	Which makes me wonder - reading:

void SAL_CALL OWeakObject::release() throw()
{
    if (osl_decrementInterlockedCount( &m_refCount ) == 0) {
        // notify/clear all weak-refs before object's dtor is executed
        // (which may check weak-refs to this object):
        disposeWeakConnectionPoint();
        // destroy object:
        delete this;
    }
}

	Who tries to take an additional reference during the weak connection
notification process, and - what are they doing with it ? :-)

	Anyhow - the suggestion is, assuming we can find/cleanup this sort of
badness [ incidentally a GObject takes a reference on itself during it's
destruction to avoid double destruction ], is it a good idea to have an
abort/assert whatever is fashionable in run-time code so we can be
confident that we have caught these cases earlier ? I for one prefer an
assertion-fail abort-app to a hard-to-catch memory corrupter later.

	Thoughts ?

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot