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

Reply via email to