You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@celix.apache.org by Alexander Broekhuis <a....@gmail.com> on 2015/02/16 09:30:27 UTC

Re: [jira] [Created] (CELIX-222) Memory used by libxml2 not released at program close.

Hm this again looks like something that I don't like when looking at OSGi
and bundles..

Copying from the libxml2 docs [1]: "It's sometimes very hard to guess if
libxml2 is in use in the application, some libraries or plugins may use it
without notice. In case of doubt abstain from calling this function or do
it just before calling exit() to avoid leak reports from valgrind !"

So while I do see the problem, the leaks are a result of libxml, and as
such there is no memory that needs to be cleared during runtime, and I
don't think there is a risk of increasing memory during the lifetime of the
application.

So I'll look into the issue, and some nice solution that also includes the
curl init/destroy, but also going to give it a lower priority. If there is
a good reason for not doing this, please let me know.

[1]: http://www.xmlsoft.org/html/libxml-parser.html#xmlCleanupParser

2015-02-11 21:48 GMT+01:00 Daniel Parker (JIRA) <ji...@apache.org>:

> Daniel Parker created CELIX-222:
> -----------------------------------
>
>              Summary: Memory used by libxml2 not released at program close.
>                  Key: CELIX-222
>                  URL: https://issues.apache.org/jira/browse/CELIX-222
>              Project: Celix
>           Issue Type: Bug
>             Reporter: Daniel Parker
>             Priority: Trivial
>
>
> There are a few memory leaks reported by valgrind for libxml2.  These can
> probably be fixed by calling xmlCleanupParser() after the bundles which use
> libxml2 are done, but before the libxml2 library is unloaded.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>



-- 
Met vriendelijke groet,

Alexander Broekhuis

RE: [jira] [Created] (CELIX-222) Memory used by libxml2 not released at program close.

Posted by Daniel Parker <Da...@myfuelmaster.com>.
I agree that this is a low priority thing (I gave it a priority of "Trivial" when creating it).

Daniel Parker

-----Original Message-----
From: Alexander Broekhuis [mailto:a.broekhuis@gmail.com] 
Sent: Monday, February 16, 2015 03:30
To: Dev
Subject: Re: [jira] [Created] (CELIX-222) Memory used by libxml2 not released at program close.

Hm this again looks like something that I don't like when looking at OSGi and bundles..

Copying from the libxml2 docs [1]: "It's sometimes very hard to guess if
libxml2 is in use in the application, some libraries or plugins may use it without notice. In case of doubt abstain from calling this function or do it just before calling exit() to avoid leak reports from valgrind !"

So while I do see the problem, the leaks are a result of libxml, and as such there is no memory that needs to be cleared during runtime, and I don't think there is a risk of increasing memory during the lifetime of the application.

So I'll look into the issue, and some nice solution that also includes the curl init/destroy, but also going to give it a lower priority. If there is a good reason for not doing this, please let me know.

[1]: http://www.xmlsoft.org/html/libxml-parser.html#xmlCleanupParser

2015-02-11 21:48 GMT+01:00 Daniel Parker (JIRA) <ji...@apache.org>:

> Daniel Parker created CELIX-222:
> -----------------------------------
>
>              Summary: Memory used by libxml2 not released at program close.
>                  Key: CELIX-222
>                  URL: https://issues.apache.org/jira/browse/CELIX-222
>              Project: Celix
>           Issue Type: Bug
>             Reporter: Daniel Parker
>             Priority: Trivial
>
>
> There are a few memory leaks reported by valgrind for libxml2.  These 
> can probably be fixed by calling xmlCleanupParser() after the bundles 
> which use
> libxml2 are done, but before the libxml2 library is unloaded.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>



--
Met vriendelijke groet,

Alexander Broekhuis