You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Björn Kremer <bk...@patorg.de> on 2013/05/15 14:48:04 UTC

Memory leak in DotCMIS

Hello,

I have just found a serious memory leak in dotcmis. The function 
"DeserializeElement" in converter.cs is leaking. I have tried to load a 
type definition multiple times without reusing the session object.(I 
have always created a new one.) The type definition contains a large set 
of "choices". Doing so will flood the memory. The memory leak is located 
in the XmlSerializer constructor. Please take a look at this article 
describing the issue: http://www-jo.se/f.pfleger/memoryleak Microsofts 
suggestion is to reuse the XmlSerializer class or to use another 
constructor.

Thank You
Björn

Re: Memory leak in DotCMIS

Posted by Florian Müller <fm...@apache.org>.
 Hi Björn,

 Thanks for that hint.
 Please open an bug report in the Apache JIRA [1].

 Thanks,

 Florian


 [1] https://issues.apache.org/jira/browse/CMIS


> Hello,
>
> I have just found a serious memory leak in dotcmis. The function
> "DeserializeElement" in converter.cs is leaking. I have tried to load
> a type definition multiple times without reusing the session 
> object.(I
> have always created a new one.) The type definition contains a large
> set of "choices". Doing so will flood the memory. The memory leak is
> located in the XmlSerializer constructor. Please take a look at this
> article describing the issue: http://www-jo.se/f.pfleger/memoryleak
> Microsofts suggestion is to reuse the XmlSerializer class or to use
> another constructor.
>
> Thank You
> Björn

Re: Memory leak in DotCMIS

Posted by Florian Müller <fm...@apache.org>.
 Hi Björn,

 I have checked in a fix for this issue.
 It works here for me. Could you please verify if it solves your 
 problem? If so, we can close the JIRA issue.


 Thanks,

 Florian


> Hello,
>
> I have just found a serious memory leak in dotcmis. The function
> "DeserializeElement" in converter.cs is leaking. I have tried to load
> a type definition multiple times without reusing the session 
> object.(I
> have always created a new one.) The type definition contains a large
> set of "choices". Doing so will flood the memory. The memory leak is
> located in the XmlSerializer constructor. Please take a look at this
> article describing the issue: http://www-jo.se/f.pfleger/memoryleak
> Microsofts suggestion is to reuse the XmlSerializer class or to use
> another constructor.
>
> Thank You
> Björn