On Feb 17, 2005, at 5:04 PM, Kevin Tew wrote:
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)
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.
You should be able to force use of a static APR-1 by editing the Makefile. If you search it for apr-1, you should see a line like:
LDFLAGS = -L/usr/local/apr/lib -lapr-1 -lrt -lcrypt -lpthread -ldl
If you changed it to something like:
LDFLAGS = -Bstatic -L/usr/local/apr/lib -lapr-1 -Bdynamic -lrt -lcrypt -lpthread -ldl
You should link with /usr/local/apr/lib/libapr-1.a instead of libapr-1.so.
Obviously it would be nice to have the default to be static and have a switch on configure that would allow you to override it. I've added that to the comments for the open issue to rework the autoconf/automake build (http://issues.apache.org/jira/browse/LOGCXX-43).
The crash does seem consistent with calling apr_atomic_inc32 before APR has been initialized and there did seem to be the opportunity for that to happen before my recent changes to Level. However, having both apr-0 and apr-1 as shared libraries in the same process could have the same outcome.
