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

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@suse.com  <><, Pseudo Engineer, itinerant idiot