[
https://issues.apache.org/jira/browse/LOGCXX-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17458854#comment-17458854
]
Truman Lackey edited comment on LOGCXX-537 at 12/14/21, 2:31 AM:
-----------------------------------------------------------------
I looked at the test issues on a mac and it irelated to a low
setReconnectionDealy in the wait_for in monitor(). I think the monitor thread
is exiting before the first message is event sent or possibly before the
connection is completed.
was (Author: JIRAUSER281485):
I looked at the test issues on a mac and it irelated to a low
setReconnectionDealy in the wait_for in monitor(). I am guessing that it is
causing thread starvation. Adding a 50 ms thread sleep before the wait_for
call fixed it in my testing. For some reason a 1ms wait_for or thread sleep is
not enough time on macos to trigger a context switch. I don't use macos and
this is the first time I can recall ever seeing this.
> double mutex lock
> -----------------
>
> Key: LOGCXX-537
> URL: https://issues.apache.org/jira/browse/LOGCXX-537
> Project: Log4cxx
> Issue Type: Bug
> Components: Appender
> Affects Versions: 0.12.1
> Environment: Ubuntu 18.04
> Reporter: Truman Lackey
> Priority: Major
> Fix For: 0.13.0
>
>
> There is a possibility of the SocketAppender calling
> std::unique_lock<log4cxx::shared_mutex> lock(mutex) twice causing a deadlock
> exception. In socketappenderskeleton.cpp connect call if the exception is
> caught on line 118 then fireConnector() will be called. On line 160 the
> mutex is attempted to be locked again but it has already been locked in the
> appendersleketo.cpp doAppend call. This causes log4cxx to throw a
> std::err::resource_deadlock_would_occur
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
