SIGSEGV in apr_atomic_xchg32

[Tanguy Le Gall <ta...@airfrance.fr>]

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 

Re: SIGSEGV in apr_atomic_xchg32

[Curt Arnold <ca...@apache.org>]

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.