logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unnikrishnan Udinoor" <uudin...@Brocade.COM>
Subject RE: Segfault on application exit (sometimes)
Date Wed, 18 Mar 2009 17:10:10 GMT
Hi David,

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






-----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.






Couldn't really get out of this yet.




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

From: Dale King [mailto:dalewking@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:




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 <grshore@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


> 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.


> Segmentation fault.)

>                        8 apr_atomic_dec32()

atomic/unix/apr_atomic.c:310 0xb7d1efba

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



> 0xb7e36da0

>                        6 log4cxx::Logger::releaseRef()

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

> 0xb7e20c5d

>                        5 ~ObjectPtrT()


> 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:



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







Dale King




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




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


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


    Any suggestions to prevent this segfault from occuring?






View raw message