
29 Nov
2011
29 Nov
'11
1:38 p.m.
There are rare reports of libvirt deadlocking itself which show a fork'd, but not exec'd, child process stuck in localtime_r(). This is because localtime_r() is not an async signal, so if we happened to fork() at the exact time another thread was calling localtime_r() we could get stuck with a stale lock in the child. Although we go to pains to protect the libvirt logging code by acquiring the mutex before forking, this is not sufficient, because some non-logging related code could invoke virTimestamp() which calls localtime_r() too. The only sane approach to fix this is to make our timestamp generation APIs thread safe, by doing a clean impl of gmtime() and strftime() inside libvirt using static buffers and only async safe POSIX apis.