On Nov 14, 2007, at 5:28 AM, Tanguy Le Gall wrote:
Hello,
I've been trying out log4cxx on Solaris. I'm using the Sun Compiler
CC version 5.5 on a Solaris 5.8 platform.
I've wrote a rather simple class which encapsulate the log4cxx,
however I systematically get a SIGSEGV in the APr function
apr_atomic_xchg32 as soon as I instanciate an object fro my logging
class.
The only way I got it to work is by creating a loggin object in the
main of my program.
I've seen a similar problem posted on Aug 21, 2007 by Brian under
the subject "multithread issue". It seems like the problem comes
from the initialiation of the APR.
Is this issue going to be fixed? Is there anyother way to
initialize it rather than calling the LoggerPtr constructeur?
Tanguy
Are you using the current SVN HEAD?
There have been some minor changes that should delay the first use of
apr_atomic_xchg32 until the first pointer assignment at which time
you'd expect that APR would have been initialized. That is unless
you were doing something like:
LoggerPtr logger = 0;
which does an unnecessary assignment and one that would not have
triggered an APR initialization. Any log4cxx object creation should
have triggered APR initialization, so an assignment like:
LoggerPtr logger = Logger::getLogger("foo");
should be safe, though
LoggerPtr logger(Logger::getLogger("foo"));
would be better and would not need to call apr_atomic_xchg32.
I'd like to avoid forcing a check of APR initialization on every
pointer assignment, particularly since on the most common platforms
apr_atomic_xchg32 does not require APR initialization.
log4cxx 0.9.7 did not attempt to do an atomic exchange on pointer
assignment, so dropping back to an non-atomic exchange is not likely
to create problems. You can do that by tweaking with the definition
of ObjectPtrBase::exchange in src/cpp/main/objectptr.c
Index: src/main/cpp/objectptr.cpp
===================================================================
--- src/main/cpp/objectptr.cpp (revision 594294)
+++ src/main/cpp/objectptr.cpp (working copy)
@@ -33,14 +33,7 @@
}
void* ObjectPtrBase::exchange(void** destination, void* newValue) {
-#if APR_SIZEOF_VOIDP == 4
- return (void*) apr_atomic_xchg32((volatile apr_uint32_t*)
destination,
- (apr_uint32_t) newValue);
-#else
- static Mutex mutex(APRInitializer::getRootPool());
- synchronized sync(mutex);
void* oldValue = *destination;
*destination = newValue;
return oldValue;
-#endif
}
I expect to be in the function before release. I'd like to call
InterlockedExchangePtr for Win64 and skip the synchronization for
other 64-bit OS's. The SVN HEAD of APR contains an
apr_atomic_xchgptr, so ideally configure would detect whether it was
present and use that if available, but don't see that happening.
