You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-dev@logging.apache.org by Kevin Tew <li...@ekstrom.org> on 2005/02/18 00:04:32 UTC
Re: apr-1 and apr-0 INFO
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.
>
Re: apr-1 and apr-0 INFO
Posted by Curt Arnold <ca...@apache.org>.
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.