Hi > -----Ursprungliche Nachricht----- > Von: Curt Arnold [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 10. Juni 2008 08:47 > An: Log4CXX User > Betreff: Re: Segmentation fault log4cxx 0.10.0 on app exit (Solaris 8) > > > > On Jun 9, 2008, at 8:05 PM, Allen Liu (allliu) wrote: > > > Hi Curt, > > > > I compiled log4cxx-0.10.0 with gcc on 3 Solaris 8/sparc > > workstations, 2 of which were installed with apr/apr-util 1.2.12 > > whereas the other apr/apr-util1.2.7. > > > > Before applying the objectimpl.cpp workaround you provided, > > > > 1. 'make check' would fail on unit-test with exit status 139 > > 2. a small test program I wrote got segmentation fault on exit > > > > After applying your workaround, > > > > 1. 'make check' passed on all 3 machine > > 2. my small test program still exited with 'segmentation fault' on > > the 2 machine installed with apr/apr-util 1.2.12. But it exited > > without a problem on the 3rd machine (with apr 1.2.7) > > > > Then I replaced apr/apr-util 1.2.12 with 1.2.7 on those 2 sun > > machines, > > > > 1. 'make check' passed > > 2. my small test program exited without 'segmentation fault' on all > > 3 machines > > > > > > I got the following question: > > 1. I got an impression from other posts that apr/apr-util 1.2.2 are > > officially used by log4cxx developers. Do I have to use 1.2.2? Or > > 1.2.7 should be fine? > > 2. Will there be a permanent fix to replace the workaround solution > > you provided in objectimpl.cpp? > > > > Thanks, > > Allen > > > The reason for the premature termination of APR hasn't been > identified: it may be a compiler bug or an log4cxx issue. The best > workaround for now appears to be commenting out the apr_terminate() in > src/main/cpp/aprinitialzer.cpp. However, removing the apr_terminate > call would result in more reported memory leaking from tools like > Valgrind. Until the nature of the underlying premature destruction of > APRInitializer is known, their can't be a reasonable fix. >
I have the same problem on Mac OS X. Commenting out the apr_terminate() does the job. Genarally it is a bug in log4cxx. There should not be any call to the statically initialized aprinitialzer in a destructor of any nonlocal object since the order of destruction of such objects in different compilation units is *undefined* (see "The C++ Programming Language", third edition p. 252). If the call to aprinitialzer is needed, you can't make valgrind happy ;) Lars
