[
https://issues.apache.org/jira/browse/LOGCXX-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Middleton resolved LOGCXX-485.
-------------------------------------
Resolution: Fixed
This should be fixed with [PR
#53|https://github.com/apache/logging-log4cxx/pull/53]
> Levels leak memory
> ------------------
>
> Key: LOGCXX-485
> URL: https://issues.apache.org/jira/browse/LOGCXX-485
> Project: Log4cxx
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.11.0
> Reporter: Thorsten Schöning
> Priority: Major
> Fix For: 0.12.0
>
> Attachments: Valgrind leak report.txt
>
>
> Users have reported memory leaks which were shown by Valgrind and the root
> cause of those leaks were changes I applied in rev 1566655 to fix LOGCXX-394,
> to make Levels thread-safe. Because LevelPtr is used, I expected that
> ObjectPtr is taking care of deleting the instances properly, but obviously
> that is not the case. After some discussion we came to the conclusion that
> using LevelPtr in this case is overkill at all and the leak should be fixed
> by adding class statics for each supported Level and change the available
> getters to only return "const Level&" references. it is important to note
> that we don't want to add function statics anymore, as that would reintroduce
> LOGCXX-394, but class statics only, which are/should be thread-safe.
> The problem with this approach is that the the API gets changed in a back
> incompatible way, but it should be worth it. So we don't change things for
> release 0.11.0 anymore, but instead collect patches here and/or in an
> associated branch for a later release, which might break existing code then.
> Until then we simply live with those leaks, because fixing the
> multi-threading problems is more important and there might not be any other
> easier solution to work around the problem. I tried with mutexes to
> coordinate access to the function static in some other place of the code and
> failed as well. So just changing the API to avoid all this seems the right
> thing to do.
> The following is the link with the discussion:
> http://mail-archives.apache.org/mod_mbox/logging-log4cxx-user/201610.mbox/%3C516ac3df-9119-3dc0-b7c7-5eba797a4ea5%40visualact.se%3E
--
This message was sent by Atlassian Jira
(v8.3.4#803005)