On 03/21/2012 05:34 AM, Tomer Guri wrote:
Hi all,
Though this sounds like silly question, we found production issue
which may expose a small problem with log4cxx thread safety.
We got application crash when trying to write a log line due to level
object being null and accessed.
When deeping our research we found that the way “get levels” functions
are implemented looks to us as not fully thread safety.
The way the function implemented for all log level is:
LevelPtr Level::getError() {
*static LevelPtr level(new Level(Level::ERROR_INT,
LOG4CXX_STR("ERROR"), 3));*
return level;
}
Now in case two threads are accessing the same time (_and at the first
time_) to this function the level may return null as static member is
not thread safe on windows by design.
You can see it in the below article:
*C++ scoped static initialization is not thread-safe, on purpose!*
http://blogs.msdn.com/b/oldnewthing/archive/2004/03/08/85901.aspx
This can be easily worked around by write dummy log line for each
level when application starts – making sure that level object is
initialized properly.
We succeed reproducing this issue with test application causing same
race condition and found the suggested workaround solving it.
My question to you:
1)Can you approve this is a hole in log4cxx thread safety ?
2)Did you encounter this issue before ?
3)Do you agree with the suggested workaround or did you implemented
something else ?
4)Does log4cxx should be thread safety also on multi-processor machines ?
Best Regards,
Tomer Guri
Development manager
This mail was sent via Mail-SeCure System.
What version of the compiler are you using? The new C++11 standard
requires that scoped static variables are initialized in a thread-safe
manner. I would expect that VC10/VC11 works correctly. That said, the
function as it stands is not thread-safe on older MS compilers. Your
workaround sounds reasonable.
Rob