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.
