Could you provide a testcase and/or coredump information?
Something else that may help track this down, is to see
wether the problem occurs in both static and shared library
builds.
Also if possible try rebuilding log4cpp with libtool 1.5.
Apparently libtool 1.5 has some important fixes for linking
C++ apps.
Bastiaan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have located the problem with the thread safety of
PatternLayout. The problem only occurs when you use the
%d specifier in your pattern, i.e., attempt to include time
information in your log statement. The
PatternLayout::TimeStampComponent::append method makes
a call to localtime(), which is not threadsafe on Solaris. See http://www.netsys.com/cgi-bin/man2html?ctime\(3C)
By changing this call to localtime_r (prototype is slightly
different), my threading tests passed. I should qualify that.
My threading tests passed when I used a ConsoleAppender.
When I use a RollingFileAppender, I still get a core dump.
I am trying to get to the bottom of this issue now. But at the
very least, the call to localtime needs to be changed, and
then we can use PatternLayout with a ConsoleAppender and
redirect the logs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, I posted previously that the use of localtime on Solaris
is known to *not* be threadsafe, and replacing it with
localtime_r did fix the threading issues (core dumping). There
is still a remaining issue that I am not sure if it is memory
related or threading.
If you use a %d{...} specifier for PatternLayout, if you don't
include a %l specifier to include milliseconds in the log
message, log4cpp core dumps during my threading tests. It
always passes as long as I include the %l in any custom
postfix, i.e. {...}.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: NO
asdfasf
Logged In: YES
user_id=8050
Could you provide a testcase and/or coredump information?
Something else that may help track this down, is to see
wether the problem occurs in both static and shared library
builds.
Also if possible try rebuilding log4cpp with libtool 1.5.
Apparently libtool 1.5 has some important fixes for linking
C++ apps.
Bastiaan
Logged In: NO
I have located the problem with the thread safety of
PatternLayout. The problem only occurs when you use the
%d specifier in your pattern, i.e., attempt to include time
information in your log statement. The
PatternLayout::TimeStampComponent::append method makes
a call to localtime(), which is not threadsafe on Solaris. See
http://www.netsys.com/cgi-bin/man2html?ctime\(3C)
By changing this call to localtime_r (prototype is slightly
different), my threading tests passed. I should qualify that.
My threading tests passed when I used a ConsoleAppender.
When I use a RollingFileAppender, I still get a core dump.
I am trying to get to the bottom of this issue now. But at the
very least, the call to localtime needs to be changed, and
then we can use PatternLayout with a ConsoleAppender and
redirect the logs.
Logged In: YES
user_id=890916
Okay, I posted previously that the use of localtime on Solaris
is known to *not* be threadsafe, and replacing it with
localtime_r did fix the threading issues (core dumping). There
is still a remaining issue that I am not sure if it is memory
related or threading.
If you use a %d{...} specifier for PatternLayout, if you don't
include a %l specifier to include milliseconds in the log
message, log4cpp core dumps during my threading tests. It
always passes as long as I include the %l in any custom
postfix, i.e. {...}.