logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: SIGSEGV in apr_atomic_xchg32
Date Wed, 14 Nov 2007 15:59:43 GMT

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) {
-   return (void*) apr_atomic_xchg32((volatile apr_uint32_t*)  
-                          (apr_uint32_t) newValue);
-   static Mutex mutex(APRInitializer::getRootPool());
-   synchronized sync(mutex);
     void* oldValue = *destination;
     *destination = newValue;
     return oldValue;

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.

View raw message