[ 
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)

Reply via email to