You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-dev@logging.apache.org by "Thorsten Schöning (JIRA)" <lo...@logging.apache.org> on 2016/10/27 17:04:58 UTC

[jira] [Created] (LOGCXX-485) Levels leak memory

Thorsten Schöning created LOGCXX-485:
----------------------------------------

             Summary: 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
             Fix For: 0.12.0


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/<516ac3df-9119-3dc0-b7c7-5eba797a4ea5%40visualact.se>



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)