Apache OpenOffice (AOO) Bugzilla – Issue 113606
forms: When opening a form document, it expose obvious memory leak after it is closed
Last modified: 2013-07-11 12:44:57 UTC
You can repeat the memory leak scenario by opening the attached sample file. Because the xforms::Model object is never released, so many other objects it refered to also leaks, such as all binding/submission object put into xforms::Model.mxSubmissions and xforms::Model.mxBindings. The xforms::Model object can not be released is caused by cyclic references between xforms::Model object and it's mxSubmission and mxBinding objects. Suggest to implement the xforms::Model to implement the XComponent interface, and when call xforms::Model::dispose() in SwDoc dtor api. Below call stack shows when the xforms::Model object is created. (The line No. may not be accurate.) + c40 ( 1260 - 620) 18 allocs BackTrace46DA + 10 ( 18 - 8) BackTrace46DA allocations sal3!rtl_allocateMemory+0000000D (z:\ure\sal\rtl\source\alloc_global.c, 308) frmmi!frm::Model_CreateInstance+00000036 (z:\sdk\forms\source\xforms\xforms_services.cxx, 65) cppuhelper3MSC!cppu::OSingleFactoryHelper::createInstanceEveryTime+0000011E (z:\ure\cppuhelper\source\factory.cxx, 186) cppuhelper3MSC!cppu::OSingleFactoryHelper::createInstanceWithContext+00000043 (z:\ure\cppuhelper\source\factory.cxx, 218) cppuhelper3MSC!cppu::OFactoryComponentHelper::createInstanceWithContext+000000FE (z:\ure\cppuhelper\source\factory.cxx, 502) cppuhelper3MSC!cppu::ORegistryFactoryHelper::createInstanceEveryTime+0000014B (z:\ure\cppuhelper\source\factory.cxx, 766) cppuhelper3MSC!cppu::OSingleFactoryHelper::createInstanceWithContext+00000043 (z:\ure\cppuhelper\source\factory.cxx, 218) cppuhelper3MSC!cppu::OFactoryComponentHelper::createInstanceWithContext+000000FE (z:\ure\cppuhelper\source\factory.cxx, 502) bootstrap.uno!stoc_smgr::OServiceManager::createInstanceWithContext+0000033B (z:\ure\stoc\source\servicemanager\servicemanager.cxx, 1276) bootstrap.uno!stoc_smgr::OServiceManager::createInstance+0000004B (z:\ure\stoc\source\servicemanager\servicemanager.cxx, 1387) xomi!lcl_createPropertySet+0000005C (z:\lib\xmloff\source\xforms\xformsapi.cxx, 79) xomi!lcl_createXFormsModel+0000009D (z:\lib\xmloff\source\xforms\xformsapi.cxx, 87) xomi!XFormsModelContext::XFormsModelContext+00000061 (z:\lib\xmloff\source\xforms\xformsmodelcontext.cxx, 88) xomi!createXFormsModelContext+00000054 (z:\lib\xmloff\source\xforms\xformsimport.cxx, 77) xomi!xmloff::OFormLayerXMLImport_Impl::createContext+00000198 (z:\lib\xmloff\source\forms\layerimport.cxx, 571) xomi!xmloff::OFormLayerXMLImport::createContext+0000001F (z:\lib\xmloff\source\forms\formlayerimport.cxx, 115) xomi!xmloff::OFormsRootImport::CreateChildContext+0000006A (z:\lib\xmloff\source\forms\officeforms.cxx, 74) xomi!SvXMLImport::startElement+00000505 (z:\lib\xmloff\source\core\xmlimp.cxx, 700) sax.uno!sax_expatwrap::SaxExpatParser_Impl::callbackStartElement+00000230 (z:\lib\sax\source\expatwrap\sax_expat.cxx, 826) sax.uno!call_callbackStartElement+00000014 (z:\lib\sax\source\expatwrap\sax_expat.cxx, 325) sax.uno!XML_Parse+00001AA5 sax.uno!XML_Parse+0000206B sax.uno!XML_Parse+000028D8 sax.uno!XML_Parse+00002A6E sax.uno!XML_Parse+00002B0F sax.uno!XML_Parse+0000009F sax.uno!sax_expatwrap::SaxExpatParser_Impl::parse+00000145 (z:\lib\sax\source\expatwrap\sax_expat.cxx, 760) sax.uno!sax_expatwrap::SaxExpatParser::parseStream+000004E0 (z:\lib\sax\source\expatwrap\sax_expat.cxx, 538)
Created attachment 70928 [details] form document
@mba: whose code is xmloff these days ?
There is no single xmloff maintainer. So as forms are concerned, let's start with fs.
Created attachment 79380 [details] fix code patch When loading a doc with forms, in XFormsModelContext::XFormsModelContext(), it creates a xforms::Model object, then in XFormsModelContext::HandleChild(), the created xforms::Model object is used to create XFormsBindContext and XFormsSubmissionContext objects. In their ctor apis, several binding and submission objects are created with api mxModel->createxxxx(), and put into XFormsModelContext bindings and submissions xset object. The memory leak is caused by cyclic reference between XFormsModelContext and binding/submission objects. To break the cyclic reference, in SwDoc dtor api, all binding/submission objects in XFormsModelContext xset collection object should be released at first. So the fix is to create a new method SwDoc::disposeXForms() to break the cyclic reference.
"zhangjf" committed SVN revision 1384759 into trunk: #i113606#, in SwDoc dtor to release the cyclic reference between XFormModel a...
change to resolved state
Since last SVT(r1400866) shows there is no memory leak, so close this defect as resolved.