[jira] [Resolved] (LOGCXX-384) Mutex deadlock on first log4cxx method call

["Thorsten Schöning (Jira)" <lo...@logging.apache.org>]

     [ https://issues.apache.org/jira/browse/LOGCXX-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thorsten Schöning resolved LOGCXX-384.
--------------------------------------
    Resolution: Cannot Reproduce

Because we are trying to reduce the backlog of open issues, I'm closing this one right now. The described environment in which the problem has been reported originally is pretty outdated these days and things might have been fixed already with a newer version of log4cxx and/or a new environment. If this concrete problem is still relevant for someone, feel free to reopen and provide the necessary details. Otherwise it's best to create a new issue describing the new environment and problem.

> Mutex deadlock on first log4cxx method call
> -------------------------------------------
>
>                 Key: LOGCXX-384
>                 URL: https://issues.apache.org/jira/browse/LOGCXX-384
>             Project: Log4cxx
>          Issue Type: Bug
>          Components: Appender
>    Affects Versions: 0.10.0
>         Environment: Built on Ubuntu 10.04 for x86 target machine. Log4cxx is built within Buildroot environment and compiler is uclibc.
>            Reporter: Aleksandar Zivkovic
>            Assignee: Curt Arnold
>            Priority: Major
>              Labels: log4cxx, uclibc, x86
>
> I have the similar problem as described in https://issues.apache.org/jira/browse/LOGCXX-334.
> After some investigation I have discovered the following:
> 1. when --with-charset is not specified (used default) I have the following backtrace when deadlock occurs:
> (gdb) bt
> #0  0xb75ca6d6 in syscall () from /lib/libc.so.0
> #1  0xb769e2d8 in __cxa_guard_acquire () from /usr/lib/libstdc++.so.6
> #2  0xb77db3fe in log4cxx::helpers::Transcoder::decode () from .//liblog4cxx.so.10
> #3  0xb77ce920 in log4cxx::helpers::StringHelper::toString () from .//liblog4cxx.so.10
> #4  0xb77850a8 in log4cxx::helpers::MutexException::formatMessage () from .//liblog4cxx.so.10
> #5  0xb7786585 in log4cxx::helpers::MutexException::MutexException () from .//liblog4cxx.so.10
> #6  0xb77aa2e9 in log4cxx::helpers::Mutex::Mutex () from .//liblog4cxx.so.10
> #7  0xb777193b in log4cxx::helpers::CharsetDecoder::createDefaultDecoder () from .//liblog4cxx.so.10
> #8  0xb7771a07 in log4cxx::helpers::CharsetDecoder::getDefaultDecoder () from .//liblog4cxx.so.10
> #9  0xb77db416 in log4cxx::helpers::Transcoder::decode () from .//liblog4cxx.so.10
> #10 0xb77a6a88 in log4cxx::LogManager::getLogger () from .//liblog4cxx.so.10
> #11 0xb77a21b5 in log4cxx::Logger::getLogger () from .//liblog4cxx.so.10
> #12 0x08049fd2 in main ()
> Deadlock occurs always and can easily be reproduced.
> 2. when built with --with-charset=utf-8 flag I have different behavior: deadlock doesn't appear but my application exits with the following printout:
> $ ./Logging_test
> terminate called after throwing an instance of 'log4cxx::helpers::MutexException'
>   what():  Mutex exception: stat = 70023
> Aborted
> $



--
This message was sent by Atlassian Jira
(v8.3.4#803005)