Venkatesh created LOGCXX-436: -------------------------------- Summary: Logging statement is hanging Key: LOGCXX-436 URL: https://issues.apache.org/jira/browse/LOGCXX-436 Project: Log4cxx Issue Type: Bug Components: Core, Filter Affects Versions: 0.10.0 Reporter: Venkatesh Priority: Minor
We have a standlone VC++ application and we added logging using the log4cxx0.10.0 version. The application will initiate a thread (for some time consuming operation) and if it takes more than threshold time then the main thread will kill the thread using TerminateThread method. The child thread function also has some logging prints.Log4CXX configured with rolling file appender of 1 MB size of 5 backup copies. Logging is working fine in most of the scenarios. But in some scenarios main thread logging function call is hanging after killing the child thread and hence the entire application is in hanging state. Subsequent instances of the application is also hanging. We took the full crash dumps of the application and analyzed using the WinDbg. Here is the call stack of the application 00 ntdll!NtWaitForSingleObject+0xa 01 ntdll!RtlpWaitOnCriticalSection+0xe8 02 ntdll!RtlEnterCriticalSection+0xd1 03 log4cxx!log4cxx::filter::DenyAllFilter::decide+0x194 04 log4cxx!log4cxx::helpers::synchronized::synchronized+0x31 05 log4cxx!log4cxx::Logger::callAppenders+0x81 06 log4cxx!log4cxx::Logger::forcedLog+0xe5 07 Test!CXX_LOG(int LOG_TYPE = 0n2, char * format = 0x00000001`3f2a2ad8 "Main thread pint...")+0x463 [d:\test\saf\test.cpp @ 2360] 08 test!TestFunction(int argc = 0n3, char ** argv = 0x00000001`3f2ae880, int level = 0n1)+0x586 [d:\test\saf\test.cpp @ 1634] 09 test!main(int argc = 0n4, char ** argv = 0x00000000`00282920)+0x1820 [d:\test\saf\test.cpp @ 2309] 0a test!__tmainCRTStartup(void)+0x13b [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crt0.c @ 278] 0b kernel32!BaseThreadInitThunk+0xd 0c ntdll!RtlUserThreadStart+0x1d and subsequent applications hangs for locking the file and call stack of the instance as follows ntdll!ZwLockFile+0xa KERNELBASE!LockFileEx+0xb2 kernel32!LockFileEx+0x1b log4cxx!log4cxx::filter::DenyAllFilter::decide+0x2a89 log4cxx!log4cxx::helpers::DatagramPacket::setData+0x559c log4cxx!log4cxx::helpers::FileOutputStream::write+0x82 log4cxx!log4cxx::rolling::RollingFileAppenderSkeleton::getTriggeringPolicy+0x1ca log4cxx!log4cxx::helpers::OutputStreamWriter::write+0xbe log4cxx!log4cxx::WriterAppender::subAppend+0x7c log4cxx!log4cxx::rolling::RollingFileAppenderSkeleton::subAppend+0xd0 log4cxx!log4cxx::WriterAppender::append+0x31 log4cxx!log4cxx::AppenderSkeleton::doAppend+0x293 log4cxx!log4cxx::helpers::AppenderAttachableImpl::appendLoopOnAppenders+0x40 log4cxx!log4cxx::Logger::callAppenders+0xa3 log4cxx!log4cxx::Logger::forcedLog+0xe5 test!CXX_LOG(int LOG_TYPE = 0n2, char * format = 0x00000001`3f2a3868 "Starting the application")+0x463 test!main(int argc = 0n4, char ** argv = 0x00000000`00162920)+0x1806 test!__tmainCRTStartup(void)+0x13b kernel32!BaseThreadInitThunk+0xd ntdll!RtlUserThreadStart+0x21 We have checked the function 'decide' and it has nothing to do with locking. it is jusing returning some constant value. I have read that LOG4CXX is thread safe. This issue is not occuring frequently and hence we didn't have the steps to rpoduce in consistent way. Is it anything needs to be addressed when we killing the child thread?? -- This message was sent by Atlassian JIRA (v6.2#6252)