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...
Status: CLOSED FIXED
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
URL:
Keywords:
Depends on:
Blocks: 120975 121366
  Show dependency tree
 
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: ---


Attachments
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)
	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)
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.