Hello Besides those problems reported earlier and having those fixes from the patch tracker that I run to keep them at bay I have this one:
==12118== Invalid read of size 4 ==12118== at 0x4E23D99: std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) (in /usr/lib64/gcc/x86_64-pc-linux-gnu/3.4.5/libstdc++.so.6.0.3) ==12118== by 0x570B2D3: log4cxx::NDC::get() (ndc.cpp:106) ==12118== by 0x5700E74: log4cxx::spi::LoggingEvent::getNDC() const (basic_string.h:428) ==12118== by 0x570A14B: log4cxx::pattern::NDCPatternConverter::format(log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggingEvent> const&, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&, log4cxx::helpers::Pool&) const (objectptr.h:160) ==12118== by 0x5713735: log4cxx::PatternLayout::format(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&, log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggingEvent> const&, log4cxx::helpers::Pool&) const (objectptr.h:614) ==12118== by 0x574F840: log4cxx::WriterAppender::subAppend(log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggingEvent> const&, log4cxx::helpers::Pool&) (objectptr.h:159) ==12118== by 0x56B568E: log4cxx::AppenderSkeleton::doAppend(log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggingEvent> const&, log4cxx::helpers::Pool&) (appenderskeleton.cpp:125) ==12118== Address 0x6CEF880 is 16 bytes inside a block of size 44 free'd ==12118== at 0x4A19B43: operator delete(void*) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==12118== by 0x4E23FC1: std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_Rep::_M_destroy(std::allocator<wchar_t> const&) (in /usr/lib64/gcc/x86_64-pc-linux-gnu/3.4.5/libstdc++.so.6.0.3) ==12118== by 0x570AAFD: __tcf_0 (basic_string.h:220) ==12118== by 0x5A6DF04: exit (in /lib64/tls/libc-2.3.5.so) ==12118== by 0x5A5967A: __libc_start_main (in /lib64/tls/libc-2.3.5.so) So... To me it seems that the problem is because the method getNull() returns a static local variable of that function which local variable (considering the order of calling static destructors in the reverse order of the constructors) is called and returns an invalid value from one of my log4cxx object users that try to log something from the destructor. So if static object your destructor tries to use log4cxx and the first time you called getNull() (indirectly by logging something in log4cxx of course) was AFTER your object gets constructed then because the order of calling static object destructors is the reverse of the constructors calls the local variable destructor will free the memory of the std::string before your logging call from the destructor of your object needs it. What do you think ? -- Mihai RUSU Email: [EMAIL PROTECTED] GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net "Linux is obsolete" -- AST
