I'm not even sure we develop that. Do you mean log4cxx? On 12 December 2017 at 03:26, Subranshu Patel <[email protected]> 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 <[email protected]>
