Cannot figure out how to clean correctly

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Cannot figure out how to clean correctly

Peter Westman
Hi,

First off, let me say that we've been using log4cxx for some years now with great success. Its a wonderful library that really helps with debugging and supporting code. Ive been using the log4cxx 0.10.0, but upgraded to the svn trunk (r1755031) last week after having issues with SocketHubAppenders. Now Im getting problems with my valgrind tests.

I get tons of valgrind errors (112 to be exact), either starting at log4cxx::Logger::getLogger() or log4cxx::xml::DOMConfigurator::configure(). I feel like I'm missing some cleanup function, but log4cxx::xml::DOMConfigurator::configure() and log4cxx::xml::DOMConfigurator::resetConfiguration() are the only ones I can find and none help. I'm sure I've missed something, but can't seem to find out what. Please help me if anyone can see my error.

Here's a minimal example:

C++ code:

#include <log4cxx/xml/domconfigurator.h>
#include <log4cxx/logger.h>
#include <log4cxx/logmanager.h>
#include <iostream>

using namespace log4cxx;
using namespace std;

int main() {
log4cxx::xml::DOMConfigurator::configure("logging.xml");

    LoggerPtr logger = Logger::getLogger("a.b");
    LOG4CXX_INFO(logger, "asdf");
    LOG4CXX_FATAL(logger, "asdf");
    cout << "asdf" << endl;

    log4cxx::LogManager::shutdown();
    log4cxx::LogManager::resetConfiguration();

    return 0;
}


logging.xml contents:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"
        debug="false" threshold="trace">
    <appender name="FileOut" class="org.apache.log4j.FileAppender">
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="%d{ISO8601} %p %F:%L %c - %m%n" />
        </layout>
        <param name="File" value="out.log" />
        <param name="Append" value="true" />
        <param name="Threshold" value="trace" />
    </appender>

    <root>
        <appender-ref ref="FileOut" />
        <level value="debug" />
    </root>
</log4j:configuration>


Built using:
#uname -r
3.12-0.bpo.1-amd64

#g++ --version
g++ (Debian 4.4.5-8) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Thank you in advance
Peter
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cannot figure out how to clean correctly

Peter Westman
Yes, its resource leaks. The 122 errors was from another logging.xml
then the one supplied in my example (it had an async appender in root,
with a file and console appender under it), with the example I sent it
is actually 22 errors (see below). The invalid free is most likely
something to do with gcc and can be ignored, but the others look to me
like things I expect LogManager::shutdown() to clean up by looking at
the code.


These are the errors I get:

==1019== Memcheck, a memory error detector
==1019== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1019== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==1019== Command: ./a.out
==1019== Parent PID: 29912
==1019==
==1019== Invalid free() / delete / delete[]
==1019==    at 0x48CAB6A: free (vg_replace_malloc.c:366)
==1019==    by 0x710E7F3: free_mem (in /lib/libc-2.11.3.so)
==1019==    by 0x710E2B9: __libc_freeres (in /lib/libc-2.11.3.so)
==1019==    by 0x48C24D3: _vgnU_freeres (vg_preloaded.c:62)
==1019==    by 0x7032067: __run_exit_handlers (exit.c:93)
==1019==    by 0x703211E: exit (exit.c:100)
==1019==    by 0x7019C9D: (below main) (libc-start.c:260)
==1019==  Address 0x4bf4498 is not stack'd, malloc'd or (recently) free'd
==1019==
==1019==
==1019== HEAP SUMMARY:
==1019==     in use at exit: 74,161 bytes in 22 blocks
==1019==   total heap usage: 1,487 allocs, 1,467 frees, 119,244 bytes
allocated
==1019==
==1019== 8 bytes in 1 blocks are indirectly lost in loss record 1 of 22
==1019==    at 0x48CB71C: operator new(unsigned int)
(vg_replace_malloc.c:255)
==1019==    by 0x49B071A: std::_Rb_tree<std::string,
std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > >,
std::_Select1st<std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > > >
 >::_M_insert_(std::_Rb_tree_node_base const*, std::_Rb_tree_node_base
const*, std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > >
const&) (new_allocator.h:89)
==1019==    by 0x49B0A32: std::_Rb_tree<std::string,
std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > >,
std::_Select1st<std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > > >
 >::_M_insert_unique(std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > >
const&) (stl_tree.h:1177)
==1019==    by 0x49AF0FD:
log4cxx::Hierarchy::updateParents(log4cxx::helpers::ObjectPtrT<log4cxx::Logger>)
(stl_map.h:500)
==1019==    by 0x49AF6F4: log4cxx::Hierarchy::getLogger(std::string
const&, log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerFactory>
const&) (hierarchy.cpp:237)
==1019==    by 0x49ACB66: log4cxx::Hierarchy::getLogger(std::string
const&) (hierarchy.cpp:210)
==1019==    by 0x49C9094: log4cxx::LogManager::getLoggerLS(std::string
const&) (logmanager.cpp:106)
==1019==    by 0x49C91A6: log4cxx::LogManager::getLogger(std::string
const&) (logmanager.cpp:121)
==1019==    by 0x49C23B1: log4cxx::Logger::getLogger(char const*)
(logger.cpp:499)
==1019==    by 0x80493F3: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 14 bytes in 1 blocks are indirectly lost in loss record 2 of 22
==1019==    at 0x48CB71C: operator new(unsigned int)
(vg_replace_malloc.c:255)
==1019==    by 0x6DB6795: std::string::_Rep::_S_create(unsigned int,
unsigned int, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.13)
==1019==    by 0x6DB77C3: ??? (in /usr/lib/libstdc++.so.6.0.13)
==1019==    by 0x6DB7A41: std::basic_string<char,
std::char_traits<char>, std::allocator<char> >::basic_string(std::string
const&, unsigned int, unsigned int) (in /usr/lib/libstdc++.so.6.0.13)
==1019==    by 0x49AED78:
log4cxx::Hierarchy::updateParents(log4cxx::helpers::ObjectPtrT<log4cxx::Logger>)
(basic_string.h:2003)
==1019==    by 0x49AF6F4: log4cxx::Hierarchy::getLogger(std::string
const&, log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerFactory>
const&) (hierarchy.cpp:237)
==1019==    by 0x49ACB66: log4cxx::Hierarchy::getLogger(std::string
const&) (hierarchy.cpp:210)
==1019==    by 0x49C9094: log4cxx::LogManager::getLoggerLS(std::string
const&) (logmanager.cpp:106)
==1019==    by 0x49C91A6: log4cxx::LogManager::getLogger(std::string
const&) (logmanager.cpp:121)
==1019==    by 0x49C23B1: log4cxx::Logger::getLogger(char const*)
(logger.cpp:499)
==1019==    by 0x80493F3: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 16 bytes in 1 blocks are indirectly lost in loss record 3 of 22
==1019==    at 0x48CB71C: operator new(unsigned int)
(vg_replace_malloc.c:255)
==1019==    by 0x6DB6795: std::string::_Rep::_S_create(unsigned int,
unsigned int, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.13)
==1019==    by 0x6DB7BA7:
std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned int)
(in /usr/lib/libstdc++.so.6.0.13)
==1019==    by 0x6DB828C: std::string::reserve(unsigned int) (in
/usr/lib/libstdc++.so.6.0.13)
==1019==    by 0x4A1AE2E:
log4cxx::helpers::Transcoder::decode(std::string const&, std::string&)
(transcoder.cpp:248)
==1019==    by 0x49C9197: log4cxx::LogManager::getLogger(std::string
const&) (logmanager.cpp:120)
==1019==    by 0x49C23B1: log4cxx::Logger::getLogger(char const*)
(logger.cpp:499)
==1019==    by 0x80493F3: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 17 bytes in 1 blocks are indirectly lost in loss record 4 of 22
==1019==    at 0x48CB71C: operator new(unsigned int)
(vg_replace_malloc.c:255)
==1019==    by 0x6DB6795: std::string::_Rep::_S_create(unsigned int,
unsigned int, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.13)
==1019==    by 0x6DB7493: ??? (in /usr/lib/libstdc++.so.6.0.13)
==1019==    by 0x6DB7685: std::basic_string<char,
std::char_traits<char>, std::allocator<char> >::basic_string(char
const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.13)
==1019==    by 0x49F6A4A:
log4cxx::spi::RootLogger::RootLogger(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::Level> const&) (rootlogger.cpp:28)
==1019==    by 0x49AD116: log4cxx::Hierarchy::Hierarchy() (hierarchy.cpp:58)
==1019==    by 0x49C8A8D: log4cxx::LogManager::getLoggerRepository()
(logmanager.cpp:87)
==1019==    by 0x4998C5A:
log4cxx::xml::DOMConfigurator::configure(std::string const&)
(domconfigurator.cpp:766)
==1019==    by 0x8049396: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 18 bytes in 1 blocks are indirectly lost in loss record 5 of 22
==1019==    at 0x48CB71C: operator new(unsigned int)
(vg_replace_malloc.c:255)
==1019==    by 0x6DB6795: std::string::_Rep::_S_create(unsigned int,
unsigned int, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.13)
==1019==    by 0x6DB7493: ??? (in /usr/lib/libstdc++.so.6.0.13)
==1019==    by 0x6DB7685: std::basic_string<char,
std::char_traits<char>, std::allocator<char> >::basic_string(char
const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.13)
==1019==    by 0x49B75CB: log4cxx::Level::getDebug() (level.cpp:53)
==1019==    by 0x49B7D1F: log4cxx::Level::toLevelLS(std::string const&,
log4cxx::helpers::ObjectPtrT<log4cxx::Level> const&) (level.cpp:190)
==1019==    by 0x49DB7FD:
log4cxx::helpers::OptionConverter::toLevel(std::string const&,
log4cxx::helpers::ObjectPtrT<log4cxx::Level> const&)
(optionconverter.cpp:261)
==1019==    by 0x4991D19:
log4cxx::xml::DOMConfigurator::parseLevel(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, log4cxx::helpers::ObjectPtrT<log4cxx::Logger>, bool)
(domconfigurator.cpp:668)
==1019==    by 0x499619A:
log4cxx::xml::DOMConfigurator::parseChildrenOfLoggerElement(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, log4cxx::helpers::ObjectPtrT<log4cxx::Logger>, bool,
apr_xml_doc*, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:495)
==1019==    by 0x49968B6:
log4cxx::xml::DOMConfigurator::parseRoot(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, apr_xml_doc*, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:449)
==1019==    by 0x4997E2A:
log4cxx::xml::DOMConfigurator::parse(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, apr_xml_doc*, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:977)
==1019==    by 0x4998890:
log4cxx::xml::DOMConfigurator::doConfigure(log4cxx::File const&,
log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerRepository>&)
(domconfigurator.cpp:758)
==1019==
==1019== 20 bytes in 1 blocks are indirectly lost in loss record 6 of 22
==1019==    at 0x48CB71C: operator new(unsigned int)
(vg_replace_malloc.c:255)
==1019==    by 0x49B75D7: log4cxx::Level::getDebug() (level.cpp:53)
==1019==    by 0x49B7D1F: log4cxx::Level::toLevelLS(std::string const&,
log4cxx::helpers::ObjectPtrT<log4cxx::Level> const&) (level.cpp:190)
==1019==    by 0x49DB7FD:
log4cxx::helpers::OptionConverter::toLevel(std::string const&,
log4cxx::helpers::ObjectPtrT<log4cxx::Level> const&)
(optionconverter.cpp:261)
==1019==    by 0x4991D19:
log4cxx::xml::DOMConfigurator::parseLevel(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, log4cxx::helpers::ObjectPtrT<log4cxx::Logger>, bool)
(domconfigurator.cpp:668)
==1019==    by 0x499619A:
log4cxx::xml::DOMConfigurator::parseChildrenOfLoggerElement(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, log4cxx::helpers::ObjectPtrT<log4cxx::Logger>, bool,
apr_xml_doc*, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:495)
==1019==    by 0x49968B6:
log4cxx::xml::DOMConfigurator::parseRoot(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, apr_xml_doc*, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:449)
==1019==    by 0x4997E2A:
log4cxx::xml::DOMConfigurator::parse(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, apr_xml_doc*, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:977)
==1019==    by 0x4998890:
log4cxx::xml::DOMConfigurator::doConfigure(log4cxx::File const&,
log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerRepository>&)
(domconfigurator.cpp:758)
==1019==    by 0x4998C7B:
log4cxx::xml::DOMConfigurator::configure(std::string const&)
(domconfigurator.cpp:766)
==1019==    by 0x8049396: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 28 bytes in 1 blocks are indirectly lost in loss record 7 of 22
==1019==    at 0x48CB71C: operator new(unsigned int)
(vg_replace_malloc.c:255)
==1019==    by 0x49B0B34: std::_Rb_tree<std::string,
std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Logger> >,
std::_Select1st<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > >
 >::_M_insert_(std::_Rb_tree_node_base const*, std::_Rb_tree_node_base
const*, std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > const&) (new_allocator.h:89)
==1019==    by 0x49B0DD2: std::_Rb_tree<std::string,
std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Logger> >,
std::_Select1st<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > >
 >::_M_insert_unique(std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > const&) (stl_tree.h:1177)
==1019==    by 0x49AF5B4: log4cxx::Hierarchy::getLogger(std::string
const&, log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerFactory>
const&) (stl_map.h:500)
==1019==    by 0x49ACB66: log4cxx::Hierarchy::getLogger(std::string
const&) (hierarchy.cpp:210)
==1019==    by 0x49C9094: log4cxx::LogManager::getLoggerLS(std::string
const&) (logmanager.cpp:106)
==1019==    by 0x49C91A6: log4cxx::LogManager::getLogger(std::string
const&) (logmanager.cpp:121)
==1019==    by 0x49C23B1: log4cxx::Logger::getLogger(char const*)
(logger.cpp:499)
==1019==    by 0x80493F3: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 32 bytes in 1 blocks are indirectly lost in loss record 8 of 22
==1019==    at 0x48CB71C: operator new(unsigned int)
(vg_replace_malloc.c:255)
==1019==    by 0x49B06AE: std::_Rb_tree<std::string,
std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > >,
std::_Select1st<std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > > >
 >::_M_insert_(std::_Rb_tree_node_base const*, std::_Rb_tree_node_base
const*, std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > >
const&) (new_allocator.h:89)
==1019==    by 0x49B0A32: std::_Rb_tree<std::string,
std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > >,
std::_Select1st<std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > > >
 >::_M_insert_unique(std::pair<std::string const,
std::vector<log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,
std::allocator<log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > > >
const&) (stl_tree.h:1177)
==1019==    by 0x49AF0FD:
log4cxx::Hierarchy::updateParents(log4cxx::helpers::ObjectPtrT<log4cxx::Logger>)
(stl_map.h:500)
==1019==    by 0x49AF6F4: log4cxx::Hierarchy::getLogger(std::string
const&, log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerFactory>
const&) (hierarchy.cpp:237)
==1019==    by 0x49ACB66: log4cxx::Hierarchy::getLogger(std::string
const&) (hierarchy.cpp:210)
==1019==    by 0x49C9094: log4cxx::LogManager::getLoggerLS(std::string
const&) (logmanager.cpp:106)
==1019==    by 0x49C91A6: log4cxx::LogManager::getLogger(std::string
const&) (logmanager.cpp:121)
==1019==    by 0x49C23B1: log4cxx::Logger::getLogger(char const*)
(logger.cpp:499)
==1019==    by 0x80493F3: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 64 bytes in 1 blocks are indirectly lost in loss record 9 of 22
==1019==    at 0x48CB71C: operator new(unsigned int)
(vg_replace_malloc.c:255)
==1019==    by 0x49AD0FE: log4cxx::Hierarchy::Hierarchy() (hierarchy.cpp:58)
==1019==    by 0x49C8A8D: log4cxx::LogManager::getLoggerRepository()
(logmanager.cpp:87)
==1019==    by 0x4998C5A:
log4cxx::xml::DOMConfigurator::configure(std::string const&)
(domconfigurator.cpp:766)
==1019==    by 0x8049396: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 64 bytes in 1 blocks are indirectly lost in loss record 10 of 22
==1019==    at 0x48CB71C: operator new(unsigned int)
(vg_replace_malloc.c:255)
==1019==    by 0x498FCB8:
log4cxx::DefaultLoggerFactory::makeNewLoggerInstance(log4cxx::helpers::Pool&,
std::string const&) const (defaultloggerfactory.cpp:29)
==1019==    by 0x49AF55B: log4cxx::Hierarchy::getLogger(std::string
const&, log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerFactory>
const&) (hierarchy.cpp:226)
==1019==    by 0x49ACB66: log4cxx::Hierarchy::getLogger(std::string
const&) (hierarchy.cpp:210)
==1019==    by 0x49C9094: log4cxx::LogManager::getLoggerLS(std::string
const&) (logmanager.cpp:106)
==1019==    by 0x49C91A6: log4cxx::LogManager::getLogger(std::string
const&) (logmanager.cpp:121)
==1019==    by 0x49C23B1: log4cxx::Logger::getLogger(char const*)
(logger.cpp:499)
==1019==    by 0x80493F3: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 78 (24 direct, 54 indirect) bytes in 1 blocks are definitely
lost in loss record 11 of 22
==1019==    at 0x48CB71C: operator new(unsigned int)
(vg_replace_malloc.c:255)
==1019==    by 0x49AD069: log4cxx::Hierarchy::Hierarchy() (hierarchy.cpp:55)
==1019==    by 0x49C8A8D: log4cxx::LogManager::getLoggerRepository()
(logmanager.cpp:87)
==1019==    by 0x4998C5A:
log4cxx::xml::DOMConfigurator::configure(std::string const&)
(domconfigurator.cpp:766)
==1019==    by 0x8049396: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 104 bytes in 1 blocks are still reachable in loss record 12 of 22
==1019==    at 0x48CAF50: malloc (vg_replace_malloc.c:236)
==1019==    by 0x4C3105E: apr_allocator_create (apr_pools.c:129)
==1019==    by 0x4C322BD: apr_pool_initialize (apr_pools.c:587)
==1019==    by 0x4C341A6: apr_initialize (start.c:55)
==1019==    by 0x4977DFC:
log4cxx::helpers::APRInitializer::APRInitializer() (aprinitializer.cpp:44)
==1019==    by 0x4977F31:
log4cxx::helpers::APRInitializer::getInstance() (aprinitializer.cpp:77)
==1019==    by 0x49780E6: log4cxx::helpers::APRInitializer::initialize()
(aprinitializer.cpp:83)
==1019==    by 0x49D4F00: log4cxx::helpers::ObjectImpl::ObjectImpl()
(objectimpl.cpp:30)
==1019==    by 0x497F19E:
log4cxx::helpers::CharsetDecoder::CharsetDecoder() (charsetdecoder.cpp:413)
==1019==    by 0x497F217:
log4cxx::helpers::CharsetDecoder::createDefaultDecoder()
(charsetdecoder.cpp:360)
==1019==    by 0x497FC06:
log4cxx::helpers::CharsetDecoder::getDefaultDecoder()
(charsetdecoder.cpp:435)
==1019==    by 0x4A1AF35:
log4cxx::helpers::Transcoder::decode(std::string const&, std::string&)
(transcoder.cpp:247)
==1019==
==1019== 251 (24 direct, 227 indirect) bytes in 1 blocks are definitely
lost in loss record 13 of 22
==1019==    at 0x48CB71C: operator new(unsigned int)
(vg_replace_malloc.c:255)
==1019==    by 0x49AD03C: log4cxx::Hierarchy::Hierarchy() (hierarchy.cpp:55)
==1019==    by 0x49C8A8D: log4cxx::LogManager::getLoggerRepository()
(logmanager.cpp:87)
==1019==    by 0x4998C5A:
log4cxx::xml::DOMConfigurator::configure(std::string const&)
(domconfigurator.cpp:766)
==1019==    by 0x8049396: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 8,192 bytes in 1 blocks are still reachable in loss record 14 of 22
==1019==    at 0x48CAF50: malloc (vg_replace_malloc.c:236)
==1019==    by 0x4C32193: apr_pool_create_ex (apr_pools.c:349)
==1019==    by 0x49E5907: log4cxx::helpers::Pool::Pool() (pool.cpp:34)
==1019==    by 0x497F22D:
log4cxx::helpers::CharsetDecoder::createDefaultDecoder()
(charsetdecoder.cpp:360)
==1019==    by 0x497FC06:
log4cxx::helpers::CharsetDecoder::getDefaultDecoder()
(charsetdecoder.cpp:435)
==1019==    by 0x4A1AF35:
log4cxx::helpers::Transcoder::decode(std::string const&, std::string&)
(transcoder.cpp:247)
==1019==    by 0x49A03CF: std::string
decodeLS<char>(std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&) (file.cpp:45)
==1019==    by 0x49A0410: log4cxx::File::File(std::string const&)
(file.cpp:51)
==1019==    by 0x4998C55:
log4cxx::xml::DOMConfigurator::configure(std::string const&)
(domconfigurator.cpp:765)
==1019==    by 0x8049396: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 8,192 bytes in 1 blocks are still reachable in loss record 15 of 22
==1019==    at 0x48CAF50: malloc (vg_replace_malloc.c:236)
==1019==    by 0x4C32193: apr_pool_create_ex (apr_pools.c:349)
==1019==    by 0x49E5907: log4cxx::helpers::Pool::Pool() (pool.cpp:34)
==1019==    by 0x49ACFE5: log4cxx::Hierarchy::Hierarchy() (hierarchy.cpp:55)
==1019==    by 0x49C8A8D: log4cxx::LogManager::getLoggerRepository()
(logmanager.cpp:87)
==1019==    by 0x4998C5A:
log4cxx::xml::DOMConfigurator::configure(std::string const&)
(domconfigurator.cpp:766)
==1019==    by 0x8049396: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 8,192 bytes in 1 blocks are still reachable in loss record 16 of 22
==1019==    at 0x48CAF50: malloc (vg_replace_malloc.c:236)
==1019==    by 0x4C32193: apr_pool_create_ex (apr_pools.c:349)
==1019==    by 0x49E5907: log4cxx::helpers::Pool::Pool() (pool.cpp:34)
==1019==    by 0x4998517:
log4cxx::xml::DOMConfigurator::doConfigure(log4cxx::File const&,
log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerRepository>&)
(domconfigurator.cpp:726)
==1019==    by 0x4998C7B:
log4cxx::xml::DOMConfigurator::configure(std::string const&)
(domconfigurator.cpp:766)
==1019==    by 0x8049396: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 8,192 bytes in 1 blocks are still reachable in loss record 17 of 22
==1019==    at 0x48CAF50: malloc (vg_replace_malloc.c:236)
==1019==    by 0x4C32193: apr_pool_create_ex (apr_pools.c:349)
==1019==    by 0x49E5907: log4cxx::helpers::Pool::Pool() (pool.cpp:34)
==1019==    by 0x498110D:
log4cxx::helpers::CharsetEncoder::createDefaultEncoder()
(charsetencoder.cpp:376)
==1019==    by 0x49819F6:
log4cxx::helpers::CharsetEncoder::getDefaultEncoder()
(charsetencoder.cpp:442)
==1019==    by 0x4A1AD53:
log4cxx::helpers::Transcoder::encode(std::string const&, std::string&)
(transcoder.cpp:288)
==1019==    by 0x4A1B1C7:
log4cxx::helpers::Transcoder::encode(std::string const&,
log4cxx::helpers::Pool&) (transcoder.cpp:277)
==1019==    by 0x49A05AF:
log4cxx::File::getPath(log4cxx::helpers::Pool&) const (file.cpp:126)
==1019==    by 0x49A08B5: log4cxx::File::open(apr_file_t**, int, int,
log4cxx::helpers::Pool&) const (file.cpp:133)
==1019==    by 0x499853D:
log4cxx::xml::DOMConfigurator::doConfigure(log4cxx::File const&,
log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerRepository>&)
(domconfigurator.cpp:729)
==1019==    by 0x4998C7B:
log4cxx::xml::DOMConfigurator::configure(std::string const&)
(domconfigurator.cpp:766)
==1019==    by 0x8049396: main (in
/home/peter/repos/git/v6.1/components/axis/component-tests/a.out)
==1019==
==1019== 8,192 bytes in 1 blocks are still reachable in loss record 18 of 22
==1019==    at 0x48CAF50: malloc (vg_replace_malloc.c:236)
==1019==    by 0x4C32193: apr_pool_create_ex (apr_pools.c:349)
==1019==    by 0x49E5907: log4cxx::helpers::Pool::Pool() (pool.cpp:34)
==1019==    by 0x4975F07: log4cxx::AppenderSkeleton::AppenderSkeleton()
(appenderskeleton.cpp:43)
==1019==    by 0x4A1D59B: log4cxx::WriterAppender::WriterAppender()
(writerappender.cpp:30)
==1019==    by 0x49A16E7: log4cxx::FileAppender::FileAppender()
(fileappender.cpp:38)
==1019==    by 0x49A35E2:
log4cxx::FileAppender::ClazzFileAppender::newInstance() const
(fileappender.h:65)
==1019==    by 0x499414A:
log4cxx::xml::DOMConfigurator::parseAppender(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, apr_xml_doc*, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:195)
==1019==    by 0x499571C:
log4cxx::xml::DOMConfigurator::findAppenderByName(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, apr_xml_doc*, std::string const&, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:141)
==1019==    by 0x49957A0:
log4cxx::xml::DOMConfigurator::findAppenderByName(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, apr_xml_doc*, std::string const&, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:145)
==1019==    by 0x4995B6B:
log4cxx::xml::DOMConfigurator::findAppenderByReference(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, apr_xml_doc*, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:169)
==1019==    by 0x4995EDD:
log4cxx::xml::DOMConfigurator::parseChildrenOfLoggerElement(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, log4cxx::helpers::ObjectPtrT<log4cxx::Logger>, bool,
apr_xml_doc*, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:477)
==1019==
==1019== 8,192 bytes in 1 blocks are still reachable in loss record 19 of 22
==1019==    at 0x48CAF50: malloc (vg_replace_malloc.c:236)
==1019==    by 0x4C32193: apr_pool_create_ex (apr_pools.c:349)
==1019==    by 0x49E5907: log4cxx::helpers::Pool::Pool() (pool.cpp:34)
==1019==    by 0x49A5559:
log4cxx::helpers::FileOutputStream::FileOutputStream(std::string const&,
bool) (fileoutputstream.cpp:35)
==1019==    by 0x49A1B03: log4cxx::FileAppender::setFile(std::string
const&, bool, bool, unsigned int, log4cxx::helpers::Pool&)
(fileappender.cpp:269)
==1019==    by 0x49A2535:
log4cxx::FileAppender::activateOptions(log4cxx::helpers::Pool&)
(fileappender.cpp:155)
==1019==    by 0x49EE836:
log4cxx::config::PropertySetter::activate(log4cxx::helpers::Pool&)
(propertysetter.cpp:102)
==1019==    by 0x4994886:
log4cxx::xml::DOMConfigurator::parseAppender(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, apr_xml_doc*, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:273)
==1019==    by 0x499571C:
log4cxx::xml::DOMConfigurator::findAppenderByName(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, apr_xml_doc*, std::string const&, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:141)
==1019==    by 0x49957A0:
log4cxx::xml::DOMConfigurator::findAppenderByName(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, apr_xml_doc*, std::string const&, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:145)
==1019==    by 0x4995B6B:
log4cxx::xml::DOMConfigurator::findAppenderByReference(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, apr_xml_doc*, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:169)
==1019==    by 0x4995EDD:
log4cxx::xml::DOMConfigurator::parseChildrenOfLoggerElement(log4cxx::helpers::Pool&,
log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder>&,
apr_xml_elem*, log4cxx::helpers::ObjectPtrT<log4cxx::Logger>, bool,
apr_xml_doc*, std::map<std::string,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender>, std::less<std::string>,
std::allocator<std::pair<std::string const,
log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > >&)
(domconfigurator.cpp:477)
==1019==
==1019== 8,192 bytes in 1 blocks are possibly lost in loss record 20 of 22
==1019==    at 0x48CAF50: malloc (vg_replace_malloc.c:236)
==1019==    by 0x4C32193: apr_pool_create_ex (apr_pools.c:349)
==1019==    by 0x4C322F7: apr_pool_initialize (apr_pools.c:592)
==1019==    by 0x4C341A6: apr_initialize (start.c:55)
==1019==    by 0x4977DFC:
log4cxx::helpers::APRInitializer::APRInitializer() (aprinitializer.cpp:44)
==1019==    by 0x4977F31:
log4cxx::helpers::APRInitializer::getInstance() (aprinitializer.cpp:77)
==1019==    by 0x49780E6: log4cxx::helpers::APRInitializer::initialize()
(aprinitializer.cpp:83)
==1019==    by 0x49D4F00: log4cxx::helpers::ObjectImpl::ObjectImpl()
(objectimpl.cpp:30)
==1019==    by 0x497F19E:
log4cxx::helpers::CharsetDecoder::CharsetDecoder() (charsetdecoder.cpp:413)
==1019==    by 0x497F217:
log4cxx::helpers::CharsetDecoder::createDefaultDecoder()
(charsetdecoder.cpp:360)
==1019==    by 0x497FC06:
log4cxx::helpers::CharsetDecoder::getDefaultDecoder()
(charsetdecoder.cpp:435)
==1019==    by 0x4A1AF35:
log4cxx::helpers::Transcoder::decode(std::string const&, std::string&)
(transcoder.cpp:247)
==1019==
==1019== 8,192 bytes in 1 blocks are possibly lost in loss record 21 of 22
==1019==    at 0x48CAF50: malloc (vg_replace_malloc.c:236)
==1019==    by 0x4C32193: apr_pool_create_ex (apr_pools.c:349)
==1019==    by 0x4C341CF: apr_initialize (start.c:58)
==1019==    by 0x4977DFC:
log4cxx::helpers::APRInitializer::APRInitializer() (aprinitializer.cpp:44)
==1019==    by 0x4977F31:
log4cxx::helpers::APRInitializer::getInstance() (aprinitializer.cpp:77)
==1019==    by 0x49780E6: log4cxx::helpers::APRInitializer::initialize()
(aprinitializer.cpp:83)
==1019==    by 0x49D4F00: log4cxx::helpers::ObjectImpl::ObjectImpl()
(objectimpl.cpp:30)
==1019==    by 0x497F19E:
log4cxx::helpers::CharsetDecoder::CharsetDecoder() (charsetdecoder.cpp:413)
==1019==    by 0x497F217:
log4cxx::helpers::CharsetDecoder::createDefaultDecoder()
(charsetdecoder.cpp:360)
==1019==    by 0x497FC06:
log4cxx::helpers::CharsetDecoder::getDefaultDecoder()
(charsetdecoder.cpp:435)
==1019==    by 0x4A1AF35:
log4cxx::helpers::Transcoder::decode(std::string const&, std::string&)
(transcoder.cpp:247)
==1019==    by 0x49A03CF: std::string
decodeLS<char>(std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&) (file.cpp:45)
==1019==
==1019== 8,192 bytes in 1 blocks are possibly lost in loss record 22 of 22
==1019==    at 0x48CAF50: malloc (vg_replace_malloc.c:236)
==1019==    by 0x4C32193: apr_pool_create_ex (apr_pools.c:349)
==1019==    by 0x4977E1C:
log4cxx::helpers::APRInitializer::APRInitializer() (aprinitializer.cpp:45)
==1019==    by 0x4977F31:
log4cxx::helpers::APRInitializer::getInstance() (aprinitializer.cpp:77)
==1019==    by 0x49780E6: log4cxx::helpers::APRInitializer::initialize()
(aprinitializer.cpp:83)
==1019==    by 0x49D4F00: log4cxx::helpers::ObjectImpl::ObjectImpl()
(objectimpl.cpp:30)
==1019==    by 0x497F19E:
log4cxx::helpers::CharsetDecoder::CharsetDecoder() (charsetdecoder.cpp:413)
==1019==    by 0x497F217:
log4cxx::helpers::CharsetDecoder::createDefaultDecoder()
(charsetdecoder.cpp:360)
==1019==    by 0x497FC06:
log4cxx::helpers::CharsetDecoder::getDefaultDecoder()
(charsetdecoder.cpp:435)
==1019==    by 0x4A1AF35:
log4cxx::helpers::Transcoder::decode(std::string const&, std::string&)
(transcoder.cpp:247)
==1019==    by 0x49A03CF: std::string
decodeLS<char>(std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&) (file.cpp:45)
==1019==    by 0x49A0410: log4cxx::File::File(std::string const&)
(file.cpp:51)
==1019==
==1019== LEAK SUMMARY:
==1019==    definitely lost: 48 bytes in 2 blocks
==1019==    indirectly lost: 281 bytes in 10 blocks
==1019==      possibly lost: 24,576 bytes in 3 blocks
==1019==    still reachable: 49,256 bytes in 7 blocks
==1019==         suppressed: 0 bytes in 0 blocks
==1019==
==1019== For counts of detected and suppressed errors, rerun with: -v
==1019== ERROR SUMMARY: 7 errors from 6 contexts (suppressed: 35 from 6)


On 10/25/2016 02:17 PM, Thorsten Schöning wrote:

> Guten Tag Peter Westman,
> am Dienstag, 25. Oktober 2016 um 13:51 schrieben Sie:
>
>> I get tons of valgrind errors (112 to be exact)[...]
> I don't know valgrind very well, so what kind of errors are you
> talking about? If it's resource leaks, some of those are known and
> accepted to fix problems with multi threading apps and such.
>
> https://issues.apache.org/jira/browse/LOGCXX-322
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cannot figure out how to clean correctly

Peter Westman
Reverting 1566655 solved the problems. I'd prefer not to have to tinker
with reverting/patching when building. Do you mind if I work on a
solution for this and post it in LOGCXX-458 if I manage to create one?

/Peter

On 10/25/2016 06:49 PM, Thorsten Schöning wrote:

> Guten Tag Peter Westman,
> am Dienstag, 25. Oktober 2016 um 14:40 schrieben Sie:
>
>> Yes, its resource leaks.
> Most of the leaks seem to have to do with levels, which were changed
> by me because of problems in multi threading apps as well. Have a look
> at the following bugs and try again with a reverted rev 1566655, which
> is were changed things.
>
> https://issues.apache.org/jira/browse/LOGCXX-394
> https://issues.apache.org/jira/browse/LOGCXX-458
>
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cannot figure out how to clean correctly

Robert Middleton
I haven't delved too deeply into the code(I don't have time today), but it looks like all that Object is doing is providing Java-like garbage collection in terms of memory management.  A quick look at the SVN history indicates that the class was first created ~2003, so would it be worth it to discard Object entirely in favor of C++11 std::shared_ptr?  It would be a rather large change but it may also fix many of the multithreading problems given the support for atomic operations on a shared_ptr.  The only other thing that it provides is casting/instanceof operations, but the cast is never used and instanceof is used in ~6 places.

-Robert Middleton

On Wed, Oct 26, 2016 at 4:39 AM, Thorsten Schöning <[hidden email]> wrote:
Guten Tag Thorsten Schöning,
am Mittwoch, 26. Oktober 2016 um 09:57 schrieben Sie:

> 458 is not the problem, 394 is why I changed things. So you need to
> find another/better workaround to fix 394 without leaking.

Another approach would be to first look at why LevelPtr doesn't seem
to delete not needed instances on app end. Creating new instances
itself shouldn't be the problem, especially if it fixes LOGCXX-394,
but I thought LevelPtr is taking care of deleting the created
instances when not needed anymore.

So maybe just focus on LevelPtr, ObjectPtr and ObjectImpl first.

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning       E-Mail: [hidden email]
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cannot figure out how to clean correctly

Peter Westman
I think going for a boost::shared_ptr could be a good idea, most
projects using something as complex as log4cxx should be able to cope
with it imho. Another option would be to use some sort of ifndef rule to
determine if boost or the current implementation is used.

For levels though, I dont really see why we even have smart pointers? We
could just as easily create the variables statically in the class, and
use them as const references to the original levels. Right now the
library is allocating new dynamic memory on a call basis, which seems
pretty wasteful to me. If we make the storage static (which it was prior
to LOG4CXX-394/r1566655 anyway). In some cases like the Logger class
that stores a changeable level it would have to be a plain pointer, but
I personally dont see a problem with that.

/Peter

On 10/27/2016 08:48 AM, Thorsten Schöning wrote:

> Guten Tag Robert Middleton,
> am Donnerstag, 27. Oktober 2016 um 01:39 schrieben Sie:
>
>> I haven't delved too deeply into the code(I don't have time today),
>> but it looks like all that Object is doing is providing Java-like
>> garbage collection in terms of memory management.
> That was my understanding as well, but than Valgrind shouldn't find
> leaks?
>
>> A quick look at
>> the SVN history indicates that the class was first created ~2003, so
>> would it be worth it to discard Object entirely in favor of C++11
>> std::shared_ptr?
> And what with all those non C++11 people out there? I'm using
> Embarcadero C++Builder for example which doesn't support C++11 very
> well with its legacy compiler and the new CLANG based ones are still
> incompatible with some projects/environments. So at least I'm not that
> interested to merge patches which make my life more difficult...
>
> How about boost::shared_ptr instead? It's no requirement currently,
> but one might argue it's not that different than e.g. apr. In my
> compiler at least boost 1.39 is provided, which would be enough for
> shared_ptr, I'm using those already. 1.39 itself is so old, that it
> might be a reasonable minimum requirement.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cannot figure out how to clean correctly

Robert Middleton
Choosing between the smart pointers should be pretty straight forward: http://stackoverflow.com/questions/7095556/how-to-handle-evolving-c-std-namespace-e-g-stdtr1shared-ptr-vs-std

This way people can use either a boost pointer or a C++11 pointer depending on their compiler.  I only suggested C++11 since it's several years old at this point and most people should be able to use the new features without problems, but if it's possible to choose between C++11/boost that solves the problem.

I think that the memory leak may be a consequence of how the Object class is implemented; references must be incremented/decremented manually, which could explain why the memory doesn't get freed.

-Robert Middleton

On Thu, Oct 27, 2016 at 3:05 AM, Peter Westman <[hidden email]> wrote:
I think going for a boost::shared_ptr could be a good idea, most projects using something as complex as log4cxx should be able to cope with it imho. Another option would be to use some sort of ifndef rule to determine if boost or the current implementation is used.

For levels though, I dont really see why we even have smart pointers? We could just as easily create the variables statically in the class, and use them as const references to the original levels. Right now the library is allocating new dynamic memory on a call basis, which seems pretty wasteful to me. If we make the storage static (which it was prior to LOG4CXX-394/r1566655 anyway). In some cases like the Logger class that stores a changeable level it would have to be a plain pointer, but I personally dont see a problem with that.

/Peter


On 10/27/2016 08:48 AM, Thorsten Schöning wrote:
Guten Tag Robert Middleton,
am Donnerstag, 27. Oktober 2016 um 01:39 schrieben Sie:

I haven't delved too deeply into the code(I don't have time today),
but it looks like all that Object is doing is providing Java-like
garbage collection in terms of memory management.
That was my understanding as well, but than Valgrind shouldn't find
leaks?

A quick look at
the SVN history indicates that the class was first created ~2003, so
would it be worth it to discard Object entirely in favor of C++11
std::shared_ptr?
And what with all those non C++11 people out there? I'm using
Embarcadero C++Builder for example which doesn't support C++11 very
well with its legacy compiler and the new CLANG based ones are still
incompatible with some projects/environments. So at least I'm not that
interested to merge patches which make my life more difficult...

How about boost::shared_ptr instead? It's no requirement currently,
but one might argue it's not that different than e.g. apr. In my
compiler at least boost 1.39 is provided, which would be enough for
shared_ptr, I'm using those already. 1.39 itself is so old, that it
might be a reasonable minimum requirement.

Mit freundlichen Grüßen,

Thorsten Schöning



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cannot figure out how to clean correctly

Peter Westman
In reply to this post by Peter Westman
I think mixing smart pointers and static class allocation would just mix
things up. We should instead choose when to use one over the other.

We are currently returning new, dynamically allocated level objects for
each call to getInfo() etc. This memory must be freed. When logging from
a logger, a call to getInfo() will allocate a new level object in a
smart pointer, which is returned, used while logging and then when the
smart pointer is destructed the dynamically allocated object is deleted.
We used to have static, dynamically created level objects, that had to
be stored in smart pointers since they were dynamically allocated. Since
they were created at runtime, it wouldn't be thread safe when two calls
would happen simultaneously to the same function.

My suggestion is to have getInfo return a const Level& instead of a
LevelPtr. This would in turn be a reference to a static class member
(allocated without new) meaning its created at compile time. Since it
isn't dynamically created, no smart pointer is needed, and it doesnt
have to be deallocated. This would be more like the initial
pre-LOG4CXX-394 implementation in that the same object is used for each
level, but we would just not have a smart pointer. Since the object is
created at compile time and never modified it would be thread safe, and
would solve LOG4CXX-322 for levels. Loggers cannot use this pattern,
since they are not known at compile time.

/Peter



On 10/27/2016 10:45 AM, Thorsten Schöning wrote:

> Guten Tag Peter Westman,
> am Donnerstag, 27. Oktober 2016 um 09:05 schrieben Sie:
>
>> For levels though, I dont really see why we even have smart pointers? We
>> could just as easily create the variables statically in the class,
> That should be thread-safe regarding LOGCXX-322 as well, shouldn't it?
>
> https://issues.apache.org/jira/browse/LOGCXX-322
>
>> and
>> use them as const references to the original levels.
> Do you suggest replacing LevelPtr as the return type of Level::get*?
>
> Because else we seem to need some LevelPtr as static base, because
> ObjectPtr-CTORs seem to only be capable of using raw pointers or
> ObjectPtrs. But if ObjectPtr leaks now, shouldn't it as well if used
> statically in the class? So one would need to find the reason for the
> leak anyway?
>
> Maybe we should enhance ObjectPtr to a mode for back compatibility
> reasons where a managed pointer is not deleted at all? This way the
> interface could stay the same and static levels instead of LevelPtrs
> could be used in the class. A new LevelPtr instance would be created
> on each invocation of Level::get*, though.
>
>> Right now the
>> library is allocating new dynamic memory on a call basis, which seems
>> pretty wasteful to me. If we make the storage static (which it was prior
>> to LOG4CXX-394/r1566655 anyway). In some cases like the Logger class
>> that stores a changeable level it would have to be a plain pointer, but
>> I personally dont see a problem with that.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cannot figure out how to clean correctly

Robert Middleton
Eventually backwards compatibility has to be broken anyway.  If the Level changes, then that would be a good time to switch over to standard(std/boost) smart pointers as well, which may break other code that depends on Object.  For the most part I don't think this will have a large impact on library-using code, as at least in my case I only use the LOG4CXX_level macros.

Perhaps it would be best to do a release of what currently exists before the backwards compatibility is broken?

-Robert Middleton

On Thu, Oct 27, 2016 at 5:50 AM, Thorsten Schöning <[hidden email]> wrote:
Guten Tag Peter Westman,
am Donnerstag, 27. Oktober 2016 um 11:11 schrieben Sie:

> My suggestion is to have getInfo return a const Level& instead of a
> LevelPtr.

But that would change the interface and "everyone" would need to change
things. On the other side, "const Level*" would at least be compatible
with the current invocation of LevelPtr on the caller side, but would
fail assignments and such as well.

So, break back compatibility and if so, with which form?

I don't use Levels in my codebase, so I'm fine with such a break. ;-)
Additionally I would prefer "const Level&" as well.

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning       E-Mail: [hidden email]
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow


Loading...