You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Subranshu Patel <sp...@gmail.com> on 2017/12/12 09:26:48 UTC

log4c deadlock?

I have observed a scenario where application goes to a deadlock state.
Suspect the reason to be log4c.

Let me explain the scenario:

1. Process P1 starts - performs log4c_init(),log4c_category_get() and
log4c_category_log_locinfo() for logging.

2. P1 creates threads - T1, T2 and T3.

3. Now process P1 forks() to create P2 and at the same time T1 is logging
using log4c_category_log_locinfo()

4. P2 invokes log4c_init(), log4c_category_get() and then invokes
log4c_category_log_locinfo(). This results in deadlock. P2 never returns
from log4c_category_log_locinfo().



My Investigation:

When T1 invokes VE_LOG and P1 invokes fork() at the same time, the
following happens

1. T1 invokes VE_LOG() and acquires mutex lock (from within log4c).

2. P1 forks at the same time and P2 is created.

3. P2 performs log4c_init() and log4c_category_log_locinfo(). Here
pthread_mutex_init() is not invoked. P2 gets the old value of the mutex.
When P2 invokes log4c_category_log_locinfo(), it waits in
pthread_mutex_lock()

4. There is no one to wake up P2 and deadlock occurs.



The issue occurs because after fork(), the lock value is not initialized
and we use pthread_mutex_lock().

I am using a rolling policy here. Let me know if log4c is safe in this kind
of scenario.

Re: log4c deadlock?

Posted by Matt Sicker <bo...@gmail.com>.
I'm not even sure we develop that. Do you mean log4cxx?

On 12 December 2017 at 03:26, Subranshu Patel <sp...@gmail.com> wrote:

> I have observed a scenario where application goes to a deadlock state.
> Suspect the reason to be log4c.
>
> Let me explain the scenario:
>
> 1. Process P1 starts - performs log4c_init(),log4c_category_get() and
> log4c_category_log_locinfo() for logging.
>
> 2. P1 creates threads - T1, T2 and T3.
>
> 3. Now process P1 forks() to create P2 and at the same time T1 is logging
> using log4c_category_log_locinfo()
>
> 4. P2 invokes log4c_init(), log4c_category_get() and then invokes
> log4c_category_log_locinfo(). This results in deadlock. P2 never returns
> from log4c_category_log_locinfo().
>
>
>
> My Investigation:
>
> When T1 invokes VE_LOG and P1 invokes fork() at the same time, the
> following happens
>
> 1. T1 invokes VE_LOG() and acquires mutex lock (from within log4c).
>
> 2. P1 forks at the same time and P2 is created.
>
> 3. P2 performs log4c_init() and log4c_category_log_locinfo(). Here
> pthread_mutex_init() is not invoked. P2 gets the old value of the mutex.
> When P2 invokes log4c_category_log_locinfo(), it waits in
> pthread_mutex_lock()
>
> 4. There is no one to wake up P2 and deadlock occurs.
>
>
>
> The issue occurs because after fork(), the lock value is not initialized
> and we use pthread_mutex_lock().
>
> I am using a rolling policy here. Let me know if log4c is safe in this kind
> of scenario.
>



-- 
Matt Sicker <bo...@gmail.com>