John Barker wrote:

We’ve seen this as well, this seems to be related:

http://www.nabble.com/Fix-possible-crash-on-exit-when-using-static-Loggers-td19473591.html

*From:* david.we...@l-3com.com [mailto:david.we...@l-3com.com]
*Sent:* 18 March 2009 17:31
*To:* Log4CXX User
*Subject:* RE: Segfault on application exit (sometimes)

I think that this is different, looking at the stack trace compared to what I'm seeing.

I'm looking at the SVN HEAD, and I think I'm going to grab that, and try compiling it.

I think our version of 0.10.0 is *really* old in comparison to this..

I'll try that, and let you guys know.

--dw

    ------------------------------------------------------------------------

    *From:* Unnikrishnan Udinoor [mailto:uudin...@brocade.com]
    *Sent:* Wednesday, March 18, 2009 12:10 PM
    *To:* Log4CXX User
    *Subject:* RE: Segfault on application exit (sometimes)

    Hi David,

    Copying a mail thread discussing similar issues. Hope this will
    help to know the root cause.

    Regards

    Unni

    -----Original Message-----
    From: Unnikrishnan Udinoor
    Sent: Thursday, May 29, 2008 2:18 PM
    To: Log4CXX User
    Subject: RE: Segmentation fault log4cxx 0.10.0 on app exit ( RH Linux)

    I am facing similar issue with Solaris.

    The following link explains my issue.

    http://mail-archives.apache.org/mod_mbox/logging-log4cxx-user/200804.mbo

    x/%3ceb4c465fc146b54daadf4c8c0637bc6202ba6...@hq-exch-4.corp.brocade.com

    %3e

    Couldn't really get out of this yet.

    Regards

    Unni

    -----Original Message-----

    From: Dale King [mailto:dalewk...@gmail.com]

    Sent: Thursday, May 29, 2008 2:06 PM

    To: Log4CXX User

    Subject: Re: Segmentation fault log4cxx 0.10.0 on app exit ( RH Linux)

    Do you have any of the network appenders or possibly the AsyncAppender

    configured? I'm guessing this is the same thread shutdown issues I

    reported on Windows in this thread:

    http://www.nabble.com/A-few-problems-to-report-to17013024.html

    The tip should be a bit better, but you might get a delay on shutdown.

    On Thu, May 29, 2008 at 3:15 PM, GregN <grsh...@yahoo.com> wrote:

    >

    > Segmentation fault on app exit.

    >

    > log4cxx, apr-1.2.12 and apr-util-1.2.12 had been build from tar
    file.

    >

    > gcc -v

    > Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs

    > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man

    > --infodir=/usr/share/info --enable-shared --enable-threads=posix

    > --disable-checking --with-system-zlib --enable-__cxa_atexit

    > --disable-libunwind-exceptions --enable-java-awt=gtk

    > --host=i386-redhat-linux

    > Thread model: posix

    > gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)

    >

    > $ uname -a

    > Linux gredhat4 2.6.9-11.EL #1 Fri May 20 18:17:57 EDT 2005 i686 i686

    i386

    > GNU/Linux

    >

    >

    > Test app successfully writes one line in log file with code:

    > int main() {

    > PropertyConfigurator::configure(LOG_PROPERTIES_FILE_LOCATION);

    > LoggerPtr LogManager::cplusLoggerPtr = Logger::getLogger("API");

    > LOG4CXX_INFO(cplusLoggerPtr , "test_info");

    > return 0;

    > }

    >

    >

    > C++ [C/C++ Local Application]

    > gdb/mi (5/29/08 2:31 PM) (Suspended)

    > Thread [1] (Suspended: Signal 'SIGSEGV' received.

    Description:

    > Segmentation fault.)

    > 8 apr_atomic_dec32()

    atomic/unix/apr_atomic.c:310 0xb7d1efba

    > 7 log4cxx::helpers::ObjectImpl::releaseRef()

    >

    /home/grn/Projects/apache-log4cxx-0.10.0/src/main/cpp/objectimpl.cpp:44

    > 0xb7e36da0

    > 6 log4cxx::Logger::releaseRef()

    > /home/grn/Projects/apache-log4cxx-0.10.0/src/main/cpp/logger.cpp:62

    > 0xb7e20c5d

    > 5 ~ObjectPtrT()

    /usr/local/include/log4cxx/helpers/objectptr.h:100

    > 0x080550e3

    > 4 __tcf_1() /home/..project specific...

    > 3 exit() 0x004ce467

    > 2 __libc_start_main() 0x004b8e2d

    > 1 _start() 0x080545ad

    >

    > Any suggestion is welcome...

    >

    > Thanks,

    > Gregory

    >

    > --

    > View this message in context:

    http://www.nabble.com/Segmentation-fault-log4cxx-0.10.0-on-app-exit-%28-

    RH-Linux%29-tp17543738p17543738.html

    > Sent from the Log4cxx - Users mailing list archive at Nabble.com.

    >

    >

--
    Dale King

    ------------------------------------------------------------------------

    *From:* david.we...@l-3com.com [mailto:david.we...@l-3com.com]
    *Sent:* Wednesday, March 18, 2009 8:29 AM
    *To:* log4cxx-user@logging.apache.org
    *Subject:* Segfault on application exit (sometimes)

    Hello,

    We're seeing a strange occurance which I'm able to reproduce
    pretty well. We're running RHEL 4.0, with LOG4CXX 0.10.0.

    The short version, is that we have objects, each with a LoggerPtr
    member variable. We init the ptr in the constructor, and are
    seeing occasional seg faults when the application terminates. (The
    application is actually a boost automated unit test).

    I've caught the segfault in DDD, and it is in Transcoder::encode,
    where the static CharsetEncoder local variable ends up being set
    to null.

    I haven't tracked down exactly *why* yet, but my gut tells me that
    it has to do with the LOG4CXX subsystem being destroyed prior to
    all of the class users being destroyed.

    So, some questions:

    Is this a reasonable hypotheses? I obviously have some more
    tracking down to do, but I will not be able to provide any core
    dump unfortunately.

    Is it a bad idea to log messages in a class destructor?

    Any suggestions to prevent this segfault from occuring?

    Thanks

    --dw


We had many problems with crashes-on-process exit() as discussed in this thread:

http://www.nabble.com/Crashes-on-exit()-from-multithreaded-program-using-log4cxx-to21502030.html

They manifested in a variety of different ways.

The underlying problem we had, fundamentally, was with initialisation (and hence destruction) order of statics in different translation units in C++

If you have an object which tries to trace in it's destructor - and it's destructor runs after that of one of the log4cxx objects - then trouble ensues.

A (slightly nasty) workaround/patch which helped us (essentially by leaking the log4cxx statics and preventing them from ever being destructed on exit - and in particular, from being destructed before they had _definitely_ been completely finished with) was attached as a patch.

Hth,

Rhosyn

Reply via email to