[
https://issues.apache.org/jira/browse/LOGCXX-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15811941#comment-15811941
]
Andrey commented on LOGCXX-430:
-------------------------------
It seems I have related crash.
{noformat}
log4cxx.dll!std::_Tree<std::_Tmap_traits<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>,log4cxx::helpers::ObjectPtrT<log4cxx::Logger>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>
>,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> const ,log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > >,0>
>::_Insert_nohint<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> const ,log4cxx::helpers::ObjectPtrT<log4cxx::Logger> >,std::_Nil>(bool
_Leftish=false,
std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> const ,log4cxx::helpers::ObjectPtrT<log4cxx::Logger> > && _Val={...},
std::_Nil _Newnode={...}) Line 1785 C++
log4cxx.dll!log4cxx::Hierarchy::getLogger(const
std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > &
name={...}, const log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerFactory> &
factory={...}) Line 224 C++
log4cxx.dll!log4cxx::Hierarchy::getLogger(const
std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > &
name={...}) Line 206 C++
> log4cxx.dll!log4cxx::LogManager::getLoggerLS(const
> std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >
> & name={...}) Line 106 C++
log4cxx.dll!log4cxx::LogManager::getLogger(const
std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
name={...}) Line 121 C++
log4cxx.dll!log4cxx::Logger::getLogger(const char * const
name=0x18622240) Line 496 C++
{noformat}
Hierarchy object seems to be destroyed already. That is possible in the case if
{{LogManager::getLoggerRepository}} is not thread-safe.
> LogManager::getRootLogger is not thread-safe
> --------------------------------------------
>
> Key: LOGCXX-430
> URL: https://issues.apache.org/jira/browse/LOGCXX-430
> Project: Log4cxx
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.10.0
> Reporter: Thorsten Schöning
> Assignee: Thorsten Schöning
> Attachments: LOGCXX-430-with-mutex-1.patch,
> LOGCXX-430-with-mutex-2.patch, LOGCXX-430.patch
>
>
> Kaspar Fischer reported following on the user mailing list:
> > I am running into a situation where calling getRootLogger()
> > concurrently from many requests results in a EXC_BAD_ACCESS:
> > liblog4cxx.10.dylib`log4cxx::LogManager::getRootLogger():
> > 0x101f180a0: pushq %rbp
> > 0x101f180a1: movq %rsp, %rbp
> > 0x101f180a4: pushq %rbx
> > 0x101f180a5: pushq %rax
> > 0x101f180a6: movq %rdi, %rbx
> > 0x101f180a9: callq 0x101f17de0 ;
> > log4cxx::LogManager::getLoggerRepository()
> > 0x101f180ae: movq 8(%rax), %rsi
> > 0x101f180b2: movq (%rsi), %rax
> > 0x101f180b5: movq %rbx, %rdi
> > 0x101f180b8: callq *120(%rax) <<<<<< THREAD 1: EXC_BAD_ACCESS
> > (code=EXC_I386_GPFLT)
> > 0x101f180bb: movq %rbx, %rax
> > 0x101f180be: addq $8, %rsp
> > 0x101f180c2: popq %rbx
> > 0x101f180c3: popq %rbp
> > 0x101f180c4: ret
> > 0x101f180c5: nopw %cs:(%rax,%rax)
> > If I replace the logging statement with a statement that writes to
> > std::cerr, I do not run into any problems.
> > I am using log4cxx 0.10.0 on MacOS 10.9.1.
> The call to getRootLogger ultimately results in:
> {CODE}
> RepositorySelectorPtr& LogManager::getRepositorySelector() {
> //
> // call to initialize APR and trigger "start" of logging clock
> //
> APRInitializer::initialize();
> static spi::RepositorySelectorPtr selector;
> return selector;
> }
> {CODE}
> It looks like we have the same problem here like in LOGCXX-394, a function
> static which is not thread-safe. Therefore we shoudl fix this like we did in
> LOGCXX-394 by removing the function static.
> Problem is that for this to work we need to change the return type of the
> function, which shouldn't be a problem because it's private, but need to
> change additional functions as well: getLoggerRepository and
> setRepositorySelector both currently rely on the current behavior of
> getRepositorySelector.
> Additionally what I don't understand is why APRInitializer is called more
> than once even if RepositorySelector only got created once because of it's
> static.
> Looks ike we need to rework the whole part, maybe make it static on a class
> level like the guard.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
