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.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
