Platform Debian sid up to date
Note I'm building using autoconf/automake and I'm supplying /usr/local/apr the configure script as the apr location
ldd liblog4cxx.so.9.0.0
libapr-1.so.0 => /usr/local/apr/lib/libapr-1.so.0 (0x40101000)
librt.so.1 => /lib/tls/librt.so.1 (0x40138000)
libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0x4013e000)
libdl.so.2 => /lib/tls/libdl.so.2 (0x4016b000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x4016e000)
libz.so.1 => /usr/lib/libz.so.1 (0x40275000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40287000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40297000)
libm.so.6 => /lib/tls/libm.so.6 (0x40351000)
libc.so.6 => /lib/tls/libc.so.6 (0x40373000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x404a7000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)tt.cpp #include "log4cxx/logger.h"
int main( int argc, char* argv )
{
log4cxx::Logger::getLogger("Kevin");
}$ g++ -I /usr/local/include/ tt.cpp -L /usr/local/lib -llog4cxx $ LD_LIBRARY_PATH=/usr/local/lib ./a.out $ g++ -I /usr/local/include/ tt.cpp -L /usr/local/lib -llog4cxx -lapr-0 $ LD_LIBRARY_PATH=/usr/local/lib ./a.out Segmentation fault
LD_LIBRARY_PATH=/usr/local/lib gdb ./a.out
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1079981888 (LWP 15464)]
0x403751ea in apr_atomic_add32 (mem=0x804f504, val=1) at atomic/unix/apr_atomic.c:213
213 apr_thread_mutex_t *lock = hash_mutex[ATOMIC_HASH(mem)];
(gdb) where
#0 0x403751ea in apr_atomic_add32 (mem=0x804f504, val=1) at atomic/unix/apr_atomic.c:213
#1 0x40375378 in apr_atomic_inc32 (mem=0x0) at atomic/unix/apr_atomic.c:273
#2 0x400ad942 in log4cxx::helpers::ObjectImpl::addRef() const (this=0x804f500) at objectimpl.cpp:34
#3 0x4009e0df in log4cxx::Level::getOff() () at objectptr.h:72
#4 0x4009eeb3 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at objectptr.h:76
#5 0x4009f25b in _GLOBAL__I__ZNK7log4cxx5Level8getClassEv () at level.cpp:208
#6 0x400e2ed5 in __do_global_ctors_aux () from /usr/local/lib/liblog4cxx.so.9
#7 0x4006d005 in _init () from /usr/local/lib/liblog4cxx.so.9
#8 0x4000c0de in call_init () from /lib/ld-linux.so.2
#9 0x4000c1ca in _dl_init_internal () from /lib/ld-linux.so.2
#10 0x40000c5d in _dl_start_user () from /lib/ld-linux.so.2
APRInitialize is getting called first.
Curt Arnold wrote:
I think that you are experiencing a different problem that you suppose, but first to the problem that you think that you are having.
My original intent was that log4cxx could be built against either APR-0 or APR-1, however there were enough differences that it was going to add a large amount of complexity.
None of the log4cxx methods take APR types, so there should be not problem having an application using both APR-0 and APR-1.
The Ant build script will build and link against static APR libraries, if no options that providing an installed APR location, like -Dapr.dir=/usr/local/lib, or explicitly requesting use of static libraries, like -Dapr.lib.type=shared, are specified. The behavior should be consistent on all platforms.
The make script predates the migration to APR, so I doubt that it gives you any control over the APR library type.
Are you sure that your log4cxx.so is linked against a shared APR-1? What happens if you do an "ldd log4cxx.so"?
Anyway, I don't think that is your problem. I reviewed the stack trace and it suggested that I might have missed an place where we could get burned by an indeterminate sequence of static initialization. That had been a cause of much grief (http://issues.apache.org/jira/browse/LOGCXX-4) and an effort was made to (almost) eliminate the use of non-local static instances. However, there the Level::DEBUG et al public static member variables were too pervasively used in client code to eliminate. The stack trace looks like the Level::OFF member variable is being initialized before APR has been initialized and reviewing the code indicated that that was indeed possible. I've committed a fix that should ensure that APR is initialized before Level::OFF is initialized by calling APRInitializer::initialize() within the Level constructor. Please update your CVS copy and see if the problem persists. If the stack trace has changed, please post.
Curt Arnold wrote:
I think that you are experiencing a different problem that you suppose, but first to the problem that you think that you are having.
My original intent was that log4cxx could be built against either APR-0 or APR-1, however there were enough differences that it was going to add a large amount of complexity.
None of the log4cxx methods take APR types, so there should be not problem having an application using both APR-0 and APR-1.
The Ant build script will build and link against static APR libraries, if no options that providing an installed APR location, like -Dapr.dir=/usr/local/lib, or explicitly requesting use of static libraries, like -Dapr.lib.type=shared, are specified. The behavior should be consistent on all platforms.
The make script predates the migration to APR, so I doubt that it gives you any control over the APR library type.
Are you sure that your log4cxx.so is linked against a shared APR-1? What happens if you do an "ldd log4cxx.so"?
Anyway, I don't think that is your problem. I reviewed the stack trace and it suggested that I might have missed an place where we could get burned by an indeterminate sequence of static initialization. That had been a cause of much grief (http://issues.apache.org/jira/browse/LOGCXX-4) and an effort was made to (almost) eliminate the use of non-local static instances. However, there the Level::DEBUG et al public static member variables were too pervasively used in client code to eliminate. The stack trace looks like the Level::OFF member variable is being initialized before APR has been initialized and reviewing the code indicated that that was indeed possible. I've committed a fix that should ensure that APR is initialized before Level::OFF is initialized by calling APRInitializer::initialize() within the Level constructor. Please update your CVS copy and see if the problem persists. If the stack trace has changed, please post.
