Issue 113606 - forms: When opening a form document, it expose obvious memory leak after it is closed
Summary: forms: When opening a form document, it expose obvious memory leak after it i...
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: 3.4.1
Hardware: All All
: P2 Trivial (vote)
Target Milestone: 4.0.0
Assignee: zhang jianfang
QA Contact: issues@tools
Depends on:
Blocks: 120975 121366
  Show dependency treegraph
Reported: 2010-08-03 09:07 UTC by zhang jianfang
Modified: 2013-07-11 12:44 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

form document (14.50 KB, application/vnd.oasis.opendocument.text)
2010-08-03 09:08 UTC, zhang jianfang
no flags Details
fix code patch (3.00 KB, patch)
2012-09-10 08:05 UTC, zhang jianfang
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description zhang jianfang 2010-08-03 09:07:32 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)
(z:\sdk\forms\source\xforms\xforms_services.cxx, 65)
(z:\ure\cppuhelper\source\factory.cxx, 186)
(z:\ure\cppuhelper\source\factory.cxx, 218)
	cppuhelper3MSC!cppu::OFactoryComponentHelper::createInstanceWithContext+000000FE (z:\ure\cppuhelper\source\factory.cxx, 502)
(z:\ure\cppuhelper\source\factory.cxx, 766)
(z:\ure\cppuhelper\source\factory.cxx, 218)
	cppuhelper3MSC!cppu::OFactoryComponentHelper::createInstanceWithContext+000000FE (z:\ure\cppuhelper\source\factory.cxx, 502)!stoc_smgr::OServiceManager::createInstanceWithContext+0000033B
(z:\ure\stoc\source\servicemanager\servicemanager.cxx, 1276)!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)
(z:\lib\xmloff\source\xforms\xformsmodelcontext.cxx, 88)
(z:\lib\xmloff\source\xforms\xformsimport.cxx, 77)
(z:\lib\xmloff\source\forms\layerimport.cxx, 571)
(z:\lib\xmloff\source\forms\formlayerimport.cxx, 115)
(z:\lib\xmloff\source\forms\officeforms.cxx, 74)
	xomi!SvXMLImport::startElement+00000505 (z:\lib\xmloff\source\core\xmlimp.cxx, 700)!sax_expatwrap::SaxExpatParser_Impl::callbackStartElement+00000230
(z:\lib\sax\source\expatwrap\sax_expat.cxx, 826)!call_callbackStartElement+00000014
(z:\lib\sax\source\expatwrap\sax_expat.cxx, 325)!XML_Parse+00001AA5!XML_Parse+0000206B!XML_Parse+000028D8!XML_Parse+00002A6E!XML_Parse+00002B0F!XML_Parse+0000009F!sax_expatwrap::SaxExpatParser_Impl::parse+00000145
(z:\lib\sax\source\expatwrap\sax_expat.cxx, 760)!sax_expatwrap::SaxExpatParser::parseStream+000004E0
(z:\lib\sax\source\expatwrap\sax_expat.cxx, 538)
Comment 1 zhang jianfang 2010-08-03 09:08:19 UTC
Created attachment 70928 [details]
form document
Comment 2 philipp.lohmann 2010-08-03 10:10:15 UTC
@mba: whose code is xmloff these days ?
Comment 3 Mathias_Bauer 2010-08-19 17:13:34 UTC
There is no single xmloff maintainer. So as forms are concerned, let's start
with fs.
Comment 4 zhang jianfang 2012-09-10 08:05:30 UTC
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.
Comment 5 SVN Robot 2012-09-14 13:26:53 UTC
"zhangjf" committed SVN revision 1384759 into trunk:
#i113606#, in SwDoc dtor to release the cyclic reference between XFormModel a...
Comment 6 zhang jianfang 2012-09-14 13:27:57 UTC
change to resolved state
Comment 7 Yan Ji 2012-11-30 04:46:54 UTC
Since last SVT(r1400866) shows there is no memory leak, so close this defect as resolved.