again some more "static" related crashes with log4cxx

[Dizzy <di...@roedu.net>]

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: dizzy@roedu.net
GPG : http://dizzy.roedu.net/dizzy-gpg.txt	WWW: 
http://dizzy.roedu.net
			"Linux is obsolete" -- AST