Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 0.10.0
    • Fix Version/s: 0.10.0
    • Component/s: Appender
    • Labels:
      None
    • Environment:
      Windows with Visual Studio 8.0 SP1.

      Description

      I'm using an AsyncAppender that's initialized/accessed through/destroyed in a DLL through multiple other DLLs. My project is fairly complex, but I've succeeded in narrowing down the problem to a simple case. The following files reproduce the problem, although not 100% of the time:

      ---------------------------------------------------------------------------------------------------------------------
      In an executable, the only file is:
      #include "..\testlog4cxxdeadlockdll\dllmethods.h"

      int main()
      {
      configure();

      log();

      shutdown();

      return 0;
      };
      ---------------------------------------------------------------------------------------------------------------------

      ---------------------------------------------------------------------------------------------------------------------
      In a DLL, the following header file:
      #define DLL_EXPORT __declspec(dllexport)
      #define DLL_IMPORT __declspec(dllimport)
      #if defined(DLLTEST)

      1. define DLLTEST_DLL DLL_EXPORT
        #else
      2. define DLLTEST_DLL DLL_IMPORT
        #endif

      DLLTEST_DLL void configure();

      DLLTEST_DLL void log();

      DLLTEST_DLL void shutdown();
      ---------------------------------------------------------------------------------------------------------------------

      ---------------------------------------------------------------------------------------------------------------------
      In the same DLL, the following CPP file:
      #define DLLTEST

      #include "dllmethods.h"

      #ifdef _MSC_VER

      1. pragma warning(push)
      2. pragma warning(disable : 4250) // Inherits via dominance.
      3. pragma warning(disable : 4251) // Class needs to have dll-interface to be used by clients.
        #endif
        #include <log4cxx/logger.h>
        #include <log4cxx/logmanager.h>
        #include <log4cxx/patternlayout.h>
        #include <log4cxx/xml/xmllayout.h>
        #include <log4cxx/asyncappender.h>
        #include <log4cxx/fileappender.h>
        #include <log4cxx/spi/loggerrepository.h>
        #include <log4cxx/defaultloggerfactory.h>
        #ifdef _MSC_VER
      4. pragma warning(pop)
        #endif

      #include <exception>
      #include <iostream>

      void configure()
      {
      ::log4cxx::LogManager::getLoggerRepository()->setConfigured(true);

      // Create an asynchronous appender which will append to other appenders.
      ::log4cxx::AsyncAppenderPtr wAsynchronousAppender(new ::log4cxx::AsyncAppender);

      { const int wBufferSize(1 << 8); const bool wBlocking (false); wAsynchronousAppender->setName(LOG4CXX_STR("AsynchronousAppender")); wAsynchronousAppender->setBufferSize(wBufferSize); wAsynchronousAppender->setBlocking(wBlocking); ::log4cxx::LoggerPtr wRoot(::log4cxx::Logger::getRootLogger()); wRoot->addAppender(wAsynchronousAppender); }

      const ::log4cxx::LogString wFileName(LOG4CXX_STR("logtest.log"));

      { const ::log4cxx::LogString sPattern (LOG4CXX_STR("%d, %c, %t, %p, %m%n")); ::log4cxx::LayoutPtr wLayout (new ::log4cxx::PatternLayout(sPattern)); const bool wAppendToFile(false); ::log4cxx::AppenderPtr wAppender (new ::log4cxx::FileAppender(wLayout, wFileName, wAppendToFile)); wAppender->setName(LOG4CXX_STR("PatternFileAppender")); wAsynchronousAppender->addAppender(wAppender); }

      // Unbuffered file appender with an XML pattern layout compatible with the log4j format (thus with Chainsaw).
      {
      ::log4cxx::xml::XMLLayoutPtr wLayout (new ::log4cxx::xml::XMLLayout);
      const bool wAppendToFile (false);
      const ::log4cxx::LogString wFileNamePostfix(LOG4CXX_STR(".xml"));
      ::log4cxx::AppenderPtr wAppender (new ::log4cxx::FileAppender(wLayout,
      wFileName + wFileNamePostfix,
      wAppendToFile));
      wAppender->setName(LOG4CXX_STR("XmlFileAppender"));
      wAsynchronousAppender->addAppender(wAppender);
      }

      const ::log4cxx::LogString wLoggerName(LOG4CXX_STR("Unknown"));
      ::log4cxx::spi::LoggerFactoryPtr wLoggerFactory(new ::log4cxx::DefaultLoggerFactory());
      ::log4cxx::LoggerPtr wLogger(::log4cxx::LogManager::getLoggerRepository()->getLogger(wLoggerName, wLoggerFactory));
      wLogger->setAdditivity(true);
      }

      void shutdown()
      {
      try
      {
      ::log4cxx::LogManager::shutdown();
      }
      catch(const std::exception & e)

      { std::cerr << "Standard exception while trying to shutdown log4cxx: " << e.what() << std::endl; }

      catch(...)

      { std::cerr << "Unknown exception while trying to shutdown log4cxx." << std::endl; }

      }

      void log()
      {
      ::log4cxx::LoggerPtr logger(::log4cxx::Logger::getLogger(LOG4CXX_STR("Unknown")));

      for(int i(0); i < 10000; ++i)
      {
      ::log4cxx::helpers::MessageBuffer oss_;
      logger->forcedLog(::log4cxx::Level::getWarn(), oss_.str(oss_ << "TEST " << i), LOG4CXX_LOCATION);
      }
      }
      ---------------------------------------------------------------------------------------------------------------------

      The problem happens when shutdown is invoked.
      AsyncAppender::close() is called, which does dispatcher.join();
      This calls Thread::join(), which does apr_status_t stat = apr_thread_join(&startStat, (apr_thread_t*) thread);
      Then in APR_DECLARE(apr_status_t) apr_thread_join(apr_status_t *retval, apr_thread_t *thd), there is rv = WaitForSingleObject(thd->td, INFINITE);

      And that's where the deadlock happens. It seems that the wait on the thread never finishes, and the process hangs.

      Please tell me if it's my usage of log4cxx that's wrong, or if there indeed is a problem with the AsyncAppender.

      1. logcxx231.tar.gz
        17 kB
        Curt Arnold
      2. crash2.png
        117 kB
        Jean-François Bastien
      3. crash1.png
        134 kB
        Jean-François Bastien

        Activity

        Hide
        Jean-François Bastien added a comment -

        Note: I'm using the SVN head from 2007/12/18.

        Show
        Jean-François Bastien added a comment - Note: I'm using the SVN head from 2007/12/18.
        Hide
        Curt Arnold added a comment -

        Project files and sample code to attempt do replicated issue.

        To use (all commands approximate):

        mkdir c:\ls-svn
        cd \ls-svn
        svn co https://svn.apache.org/repos/asf/logging/log4cxx/trunk log4cxx
        tar -xvzf apr-1.2.11-src.tar.gz
        mv apr-1.2.11 apr
        tar -xvzf aprutil-1.2.11-src.tar.gz
        mv aprutil-1.2.11 apr-util
        cd log4cxx
        tar -xvzf logcxx231.tar.gz

        Then open logcxx231/logcxx231.dsw in Visual Studio 6 or higher, set active project to console and run.

        Did not encounter any abnormal behavior, but was running with VC 6. Will try again with VC 8.

        Show
        Curt Arnold added a comment - Project files and sample code to attempt do replicated issue. To use (all commands approximate): mkdir c:\ls-svn cd \ls-svn svn co https://svn.apache.org/repos/asf/logging/log4cxx/trunk log4cxx tar -xvzf apr-1.2.11-src.tar.gz mv apr-1.2.11 apr tar -xvzf aprutil-1.2.11-src.tar.gz mv aprutil-1.2.11 apr-util cd log4cxx tar -xvzf logcxx231.tar.gz Then open logcxx231/logcxx231.dsw in Visual Studio 6 or higher, set active project to console and run. Did not encounter any abnormal behavior, but was running with VC 6. Will try again with VC 8.
        Hide
        Curt Arnold added a comment -

        Please confirm that all components (particularly the app, DLL doing the logging and log4cxx) are using consistent C run time libraries (either Multithreaded DLL or Debug Multithreaded DLL option in the build or that each of them has MSVCRTL.DLL or MSVCRTLD.DLL as a dependency with the depends tool provided in the Platform SDK or with visual Studio).

        Many log4cxx API methods take STL strings and if you do not have consistent run time libraries, you can have crashes when one RTL attempts to free memory that it did not allocate which would most frequently occur during shutdown.

        Show
        Curt Arnold added a comment - Please confirm that all components (particularly the app, DLL doing the logging and log4cxx) are using consistent C run time libraries (either Multithreaded DLL or Debug Multithreaded DLL option in the build or that each of them has MSVCRTL.DLL or MSVCRTLD.DLL as a dependency with the depends tool provided in the Platform SDK or with visual Studio). Many log4cxx API methods take STL strings and if you do not have consistent run time libraries, you can have crashes when one RTL attempts to free memory that it did not allocate which would most frequently occur during shutdown.
        Hide
        Curt Arnold added a comment -

        I was able to see the deadlock with VC9.

        Main Thread:

        ntdll.dll!77a00f34()
        [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
        ntdll.dll!77a006a0()
        kernel32.dll!777477d4()
        kernel32.dll!77747742()
        > log4cxx.dll!apr_thread_join(int * retval=0x0012fb54, apr_thread_t * thd=0x01406198) Line 155 + 0x11 bytes C
        log4cxx.dll!log4cxx::helpers::Thread::join() Line 123 + 0x10 bytes C++
        log4cxx.dll!log4cxx::AsyncAppender::close() Line 189 + 0xb bytes C++
        log4cxx.dll!log4cxx::Logger::closeNestedAppenders() Line 113 + 0x21 bytes C++
        log4cxx.dll!log4cxx::Hierarchy::shutdown() Line 309 C++
        log4cxx.dll!log4cxx::LogManager::shutdown() Line 200 + 0x1e bytes C++
        logcxx231.dll!shutdown() Line 97 + 0x8 bytes C++
        console.exe!main() Line 14 + 0x8 bytes C++
        console.exe!__tmainCRTStartup() Line 582 + 0x19 bytes C
        console.exe!mainCRTStartup() Line 399 C
        kernel32.dll!77743833()
        ntdll.dll!779da9bd()

        Dispatch thread:

        ntdll.dll!77a00f34()
        [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
        ntdll.dll!77a006a0()
        ntdll.dll!779db18c()
        ntdll.dll!779db071()
        > log4cxx.dll!apr_thread_mutex_lock(apr_thread_mutex_t * mutex=0x014020f8) Line 85 + 0xf bytes C
        log4cxx.dll!log4cxx::helpers::synchronized::synchronized(const log4cxx::helpers::Mutex & mutex1=

        {...}) Line 33 + 0xb bytes C++
        log4cxx.dll!log4cxx::Hierarchy::getLogger(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & name="Unknown", const log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerFactory> & factory={...}

        ) Line 212 + 0xf bytes C++
        log4cxx.dll!log4cxx::Hierarchy::getLogger(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & name="Unknown") Line 206 + 0x36 bytes C++
        log4cxx.dll!log4cxx::LogManager::getLoggerLS(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & name="Unknown") Line 101 + 0x26 bytes C++
        log4cxx.dll!log4cxx::Logger::getLoggerLS(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & name="Unknown") Line 612 + 0xd bytes C++
        log4cxx.dll!log4cxx::AsyncAppender::DiscardSummary::createEvent(log4cxx::helpers::Pool & p=

        {...}

        ) Line 311 + 0x70 bytes C++
        log4cxx.dll!log4cxx::AsyncAppender::dispatch(void * thread=0x01406198, void * data=0x003bfb68) Line 344 + 0x27 bytes C++
        log4cxx.dll!log4cxx::helpers::Thread::launcher(void * thread=0x01406198, void * data=0x01406188) Line 101 + 0x19 bytes C++
        log4cxx.dll!dummy_worker(void * opaque=0x01406198) Line 79 + 0x15 bytes C
        msvcr90d.dll!_callthreadstartex() Line 348 + 0xf bytes C
        msvcr90d.dll!_threadstartex(void * ptd=0x0140d370) Line 331 C
        kernel32.dll!77743833()
        ntdll.dll!779da9bd()

        The main thread is trying to shut down the hierarchy while the dispatcher is trying to place a summary event on the queue and attempts to get a Logger to fabricate a new LoggingEvent for the missed messages.

        There are a couple of things that could be done better. It is overkill LoggingEvent to have a reference to a Logger, it would be just fine (I think) for it to have the name of a logger. Having a reference to the logger itself is a holdover from log4j.

        Also, the shutdown code should make a copy of the hierarchy, clear it and then walk through the copy closing the appenders.

        Show
        Curt Arnold added a comment - I was able to see the deadlock with VC9. Main Thread: ntdll.dll!77a00f34() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] ntdll.dll!77a006a0() kernel32.dll!777477d4() kernel32.dll!77747742() > log4cxx.dll!apr_thread_join(int * retval=0x0012fb54, apr_thread_t * thd=0x01406198) Line 155 + 0x11 bytes C log4cxx.dll!log4cxx::helpers::Thread::join() Line 123 + 0x10 bytes C++ log4cxx.dll!log4cxx::AsyncAppender::close() Line 189 + 0xb bytes C++ log4cxx.dll!log4cxx::Logger::closeNestedAppenders() Line 113 + 0x21 bytes C++ log4cxx.dll!log4cxx::Hierarchy::shutdown() Line 309 C++ log4cxx.dll!log4cxx::LogManager::shutdown() Line 200 + 0x1e bytes C++ logcxx231.dll!shutdown() Line 97 + 0x8 bytes C++ console.exe!main() Line 14 + 0x8 bytes C++ console.exe!__tmainCRTStartup() Line 582 + 0x19 bytes C console.exe!mainCRTStartup() Line 399 C kernel32.dll!77743833() ntdll.dll!779da9bd() Dispatch thread: ntdll.dll!77a00f34() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] ntdll.dll!77a006a0() ntdll.dll!779db18c() ntdll.dll!779db071() > log4cxx.dll!apr_thread_mutex_lock(apr_thread_mutex_t * mutex=0x014020f8) Line 85 + 0xf bytes C log4cxx.dll!log4cxx::helpers::synchronized::synchronized(const log4cxx::helpers::Mutex & mutex1= {...}) Line 33 + 0xb bytes C++ log4cxx.dll!log4cxx::Hierarchy::getLogger(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & name="Unknown", const log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerFactory> & factory={...} ) Line 212 + 0xf bytes C++ log4cxx.dll!log4cxx::Hierarchy::getLogger(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & name="Unknown") Line 206 + 0x36 bytes C++ log4cxx.dll!log4cxx::LogManager::getLoggerLS(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & name="Unknown") Line 101 + 0x26 bytes C++ log4cxx.dll!log4cxx::Logger::getLoggerLS(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & name="Unknown") Line 612 + 0xd bytes C++ log4cxx.dll!log4cxx::AsyncAppender::DiscardSummary::createEvent(log4cxx::helpers::Pool & p= {...} ) Line 311 + 0x70 bytes C++ log4cxx.dll!log4cxx::AsyncAppender::dispatch(void * thread=0x01406198, void * data=0x003bfb68) Line 344 + 0x27 bytes C++ log4cxx.dll!log4cxx::helpers::Thread::launcher(void * thread=0x01406198, void * data=0x01406188) Line 101 + 0x19 bytes C++ log4cxx.dll!dummy_worker(void * opaque=0x01406198) Line 79 + 0x15 bytes C msvcr90d.dll!_callthreadstartex() Line 348 + 0xf bytes C msvcr90d.dll!_threadstartex(void * ptd=0x0140d370) Line 331 C kernel32.dll!77743833() ntdll.dll!779da9bd() The main thread is trying to shut down the hierarchy while the dispatcher is trying to place a summary event on the queue and attempts to get a Logger to fabricate a new LoggingEvent for the missed messages. There are a couple of things that could be done better. It is overkill LoggingEvent to have a reference to a Logger, it would be just fine (I think) for it to have the name of a logger. Having a reference to the logger itself is a holdover from log4j. Also, the shutdown code should make a copy of the hierarchy, clear it and then walk through the copy closing the appenders.
        Hide
        Curt Arnold added a comment -

        Committed a rework on LoggingEvent in rev 628234 that eliminates the need for AsyncAppender to get an actual LoggerPtr when all that is necessary is the name.

        I looked a Hierarchy and unfortunately the loop to close appenders is nested inside of two synchronization blocks so it is not trivial to rework that so it does not block everything while the AsyncAppender or any slow to close appender finishes its business. Guess that will have to wait until after 0.10.0.

        Would appreciate feedback if the LoggingEvent rework fixes your observed issue. Marking bug as closed hoping that it does. Reopen if need be.

        Show
        Curt Arnold added a comment - Committed a rework on LoggingEvent in rev 628234 that eliminates the need for AsyncAppender to get an actual LoggerPtr when all that is necessary is the name. I looked a Hierarchy and unfortunately the loop to close appenders is nested inside of two synchronization blocks so it is not trivial to rework that so it does not block everything while the AsyncAppender or any slow to close appender finishes its business. Guess that will have to wait until after 0.10.0. Would appreciate feedback if the LoggingEvent rework fixes your observed issue. Marking bug as closed hoping that it does. Reopen if need be.
        Hide
        Jean-François Bastien added a comment -

        The deadlock seems fixed.

        There nonetheless still are issues (the program crashes inside the WaitForSingleObject), albeit not in the example I provided.

        I'll attach two screenshots of the crash being debugged in my application. Let me know if the information provided isn't sufficient to pinpoint the source of the problem.

        I'm still under MSVC 8 SP1.

        Show
        Jean-François Bastien added a comment - The deadlock seems fixed. There nonetheless still are issues (the program crashes inside the WaitForSingleObject), albeit not in the example I provided. I'll attach two screenshots of the crash being debugged in my application. Let me know if the information provided isn't sufficient to pinpoint the source of the problem. I'm still under MSVC 8 SP1.
        Hide
        Jean-François Bastien added a comment -

        Screenshots of the crash.

        Show
        Jean-François Bastien added a comment - Screenshots of the crash.
        Hide
        Jean-François Bastien added a comment -

        Note: the second screenshot comes right after I do a "step into" from the first, there's no intermediate step. I could go through the assembly if necessary.

        Show
        Jean-François Bastien added a comment - Note: the second screenshot comes right after I do a "step into" from the first, there's no intermediate step. I could go through the assembly if necessary.
        Hide
        Curt Arnold added a comment -

        If the original problem was fixed and this issue is unrelated, it should be done under a different bug report yo keep things straight.

        The second screen shot seems to have a totally distinct stack trace from the first. It seems just like you began waiting for the dispatch thread to terminate and that allowed some other thread to start and it made a call to GetModuleFileNameA. That thread doesn't look like anything in log4cxx. It seems from the trace traces, that something crashed during a WaitForSingleObject, not inside a WaitForSingleObject.

        Show
        Curt Arnold added a comment - If the original problem was fixed and this issue is unrelated, it should be done under a different bug report yo keep things straight. The second screen shot seems to have a totally distinct stack trace from the first. It seems just like you began waiting for the dispatch thread to terminate and that allowed some other thread to start and it made a call to GetModuleFileNameA. That thread doesn't look like anything in log4cxx. It seems from the trace traces, that something crashed during a WaitForSingleObject, not inside a WaitForSingleObject.
        Hide
        Curt Arnold added a comment -

        Reclosing issue since new issue appears to be unrelated.

        Show
        Curt Arnold added a comment - Reclosing issue since new issue appears to be unrelated.
        Hide
        Curt Arnold added a comment -

        When you file your new bug, attaching a log from Dr. Watson would be much preferable to images. see http://support.microsoft.com/kb/308538/EN-US/. To try to analyze dead-locks, you really need to be able to figure out what is going on in the other threads. However, as you describe the second problem, it doesn't sound like a dead-lock.

        Show
        Curt Arnold added a comment - When you file your new bug, attaching a log from Dr. Watson would be much preferable to images. see http://support.microsoft.com/kb/308538/EN-US/ . To try to analyze dead-locks, you really need to be able to figure out what is going on in the other threads. However, as you describe the second problem, it doesn't sound like a dead-lock.
        Hide
        Jean-François Bastien added a comment -

        See following description.

        Show
        Jean-François Bastien added a comment - See following description.
        Hide
        Jean-François Bastien added a comment -

        See attached zip file for minidump and screenshots. Please advise if information is insufficient, and if so what other information is needed.

        I've had time to investigate a bit more. The crash I was getting was only happening when debugging the process. If the process was run without a debugger attached then it would simply deadlock (a debugger could then be attached to examine the deadlock).

        I've reduced the problem to using a smaller version of my software. I wasn't able to create a self-contained example as before, and I can't send you the application I'm using to reproduce the problem. Here are some details:

        Using log4cxx 0.10.0 RC2 built under MSVC 8 SP1 following build instructions exactly.
        Using asynchronous appender exactly as detailed in earlier example with a file and an XML file appender attached to the asynchronous.
        Launch process outside of debugger.
        Wait until fully started.
        CTRL-C (usually ends the program cleanly).
        Seems deadlocked.
        Attach to process with MSVC debugger.
        Minidump (available in zip file).
        Screenshots (available in zip file).
        Kill thread 4236 with Process Explorer.
        Process ends.
        Using only the file and XML appenders attached to the root (no asynchronous) doesn't cause a deadlock.

        The last points pretty much point to asyncappender being the source of trouble: without it there's no deadlock, and manually killing one of log4cxx's threads allows the deadlocked program to terminate.

        Please tell me if you need any further information.

        Show
        Jean-François Bastien added a comment - See attached zip file for minidump and screenshots. Please advise if information is insufficient, and if so what other information is needed. I've had time to investigate a bit more. The crash I was getting was only happening when debugging the process. If the process was run without a debugger attached then it would simply deadlock (a debugger could then be attached to examine the deadlock). I've reduced the problem to using a smaller version of my software. I wasn't able to create a self-contained example as before, and I can't send you the application I'm using to reproduce the problem. Here are some details: Using log4cxx 0.10.0 RC2 built under MSVC 8 SP1 following build instructions exactly. Using asynchronous appender exactly as detailed in earlier example with a file and an XML file appender attached to the asynchronous. Launch process outside of debugger. Wait until fully started. CTRL-C (usually ends the program cleanly). Seems deadlocked. Attach to process with MSVC debugger. Minidump (available in zip file). Screenshots (available in zip file). Kill thread 4236 with Process Explorer. Process ends. Using only the file and XML appenders attached to the root (no asynchronous) doesn't cause a deadlock. The last points pretty much point to asyncappender being the source of trouble: without it there's no deadlock, and manually killing one of log4cxx's threads allows the deadlocked program to terminate. Please tell me if you need any further information.
        Hide
        Jean-François Bastien added a comment -

        Can the cause of the problem be similar to LOGCXX-246?

        Show
        Jean-François Bastien added a comment - Can the cause of the problem be similar to LOGCXX-246 ?
        Hide
        Curt Arnold added a comment -

        Marking the initial problem as fixed.

        The second problem showed apr_thread_exit. LOGCXX-246 reported that apr_thread_exit was being called to stop an specified thread when in fact it stops the calling thread. apr_thread_exit should no longer be called anywhere in log4cxx as far as I know, so the trace backs are no longer valid.

        The initial sample code did not appear to call activateOptions on the appenders before putting them in use. It is possible that trying to close an AsycAppender that has not been properly initialized may cause a hang.

        I was not able to use the .dmp file that was in the zip file. I was expecting a file with a .log extension that was human readable.

        If a problem still persists, please create a new bug report, do not reopen this one though you can reference back to this one.

        Show
        Curt Arnold added a comment - Marking the initial problem as fixed. The second problem showed apr_thread_exit. LOGCXX-246 reported that apr_thread_exit was being called to stop an specified thread when in fact it stops the calling thread. apr_thread_exit should no longer be called anywhere in log4cxx as far as I know, so the trace backs are no longer valid. The initial sample code did not appear to call activateOptions on the appenders before putting them in use. It is possible that trying to close an AsycAppender that has not been properly initialized may cause a hang. I was not able to use the .dmp file that was in the zip file. I was expecting a file with a .log extension that was human readable. If a problem still persists, please create a new bug report, do not reopen this one though you can reference back to this one.
        Hide
        Jean-François Bastien added a comment -

        I've added calls to activateOptions as suggested, but the deadlock is still there. I'll try out the next RC to see if it does fix the issue.

        .dmp files are mini/full dumps, they can be opened by windbg or Visual Studio and give a snapshot of the crashed application.

        Show
        Jean-François Bastien added a comment - I've added calls to activateOptions as suggested, but the deadlock is still there. I'll try out the next RC to see if it does fix the issue. .dmp files are mini/full dumps, they can be opened by windbg or Visual Studio and give a snapshot of the crashed application.

          People

          • Assignee:
            Curt Arnold
            Reporter:
            Jean-François Bastien
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development