Dear Log4Cxx dev group, There is another issue that valgrind has noted. I believe this is more a valgrind or compiler related problem. So these are the two stacktraces:
(1) --- ==15459== at 0x442B980: getenv (in /lib/libc-2.5.so) ==15459== by 0x413126B: log4cxx::helpers::System::getProperty(std::string const&) (system.cpp:58) ==15459== by 0x4108F3B: log4cxx::helpers::OptionConverter::getSystemProperty(std::string const&, std::string const&) (optionconverter.cpp:261) ==15459== by 0x4101E67: log4cxx::LogManager::getLoggerRepository() (logmanager.cpp:74) ==15459== by 0x41024AD: log4cxx::LogManager::getLogger(std::string const&) (logmanager.cpp:124) ==15459== by 0x40FAD60: log4cxx::Logger::getLogger(std::string const&) (logger.cpp:473) ==15459== by 0x804B2C3: NOS::log::CLoggerImpl::CLoggerImpl(std::string const&) (LoggerFacade.cpp:88) ==15459== by 0x804AAE1: NOS::log::CLoggerFacade::CLoggerFacade(std::string const&) (LoggerFacade.cpp:158) ==15459== by 0x80495DF: __static_initialization_and_destruction_0(int, int) (example01.cpp:3) ==15459== by 0x8049708: _GLOBAL__I_main (example01.cpp:14) (2) ==14220== Invalid read of size 1 ==14220== at 0x442BCBD: (within /lib/libc-2.5.so) ==14220== by 0x442BA66: putenv (in /lib/libc-2.5.so) ==14220== by 0x4135931: log4cxx::helpers::TimeZone::TimeZone(std::string const&) (timezone.cpp:45) ==14220== by 0x4135D15: log4cxx::helpers::TimeZone::getTimeZone(std::string const&) (timezone.cpp:97) ==14220== by 0x40CCE51: __static_initialization_and_destruction_0(int, int) (dailyrollingfileappender.cpp:29) ==14220== by 0x40CCF0E: _GLOBAL__I__ZN7log4cxx15RollingCalendar12GMT_TIMEZONEE (dailyrollingfileappender.cpp:281) ==14220== by 0x413FAB1: (within /usr/local/lib/liblog4cxx.so.9.0.0) ==14220== by 0x40B2224: (within /usr/local/lib/liblog4cxx.so.9.0.0) ==14220== by 0x400DBC4: call_init (in /lib/ld-2.5.so) ==14220== by 0x400DCD0: _dl_init (in /lib/ld-2.5.so) ==14220== by 0x40008FE: (within /lib/ld-2.5.so) ==14220== Address 0x45E21CE is 14 bytes inside a block of size 16 free'd ==14220== at 0x402130B: operator delete(void*) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==14220== by 0x437CDBC: std::string::_Rep::_M_destroy(std::allocator<char> const&) (in /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8) ==14220== by 0x437F8F7: std::string::~string() (in /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8) ==14220== by 0x4135A86: log4cxx::helpers::TimeZone::TimeZone(std::string const&) (timezone.cpp:66) ==14220== by 0x4135C1F: __static_initialization_and_destruction_0(int, int) (timezone.cpp:32) ==14220== by 0x4135CD8: _GLOBAL__I__Z7getYearx (timezone.cpp:207) ==14220== by 0x413FAB1: (within /usr/local/lib/liblog4cxx.so.9.0.0) ==14220== by 0x40B2224: (within /usr/local/lib/liblog4cxx.so.9.0.0) ==14220== by 0x400DBC4: call_init (in /lib/ld-2.5.so) ==14220== by 0x400DCD0: _dl_init (in /lib/ld-2.5.so) ==14220== by 0x40008FE: (within /lib/ld-2.5.so) I could solve both valgrind reports with a local char array keeping the content of the pointers passed to 'getenv' and 'putenv'. As said before, I don't think this is a Log4Cxx issue. However, maybe it is worth someone to look over. Thanks, Gerrit Bruchhaeuser SD "Entertainment & Services" Phone +49 7248 928 - 0 Fax +49 7248 928 - 499 E-Mail [EMAIL PROTECTED] http://www.nero.com NERO - BECAUSE TECHNOLOGY COUNTS ********************************************************* Nero AG Im Stoeckmaedle 13-15 76307 Karlsbad Germany Vorstand: Richard Lesser (CEO), Kevin Dillon (CFO) Aufsichtsratvorsitzender/ chairman of the supervisory board: Jim Corbett Amtsgericht Mannheim HRB 362519 ********************************************************* This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. *********************************************************
