Description of problem:
POSIX is explicit that multi-threaded apps can only safely use async-signal-safe functions in between fork() and exec().  This is because the fork may have happened while some other thread holds a mutex, such as the malloc mutex; but the child no longer has the other thread available to release the mutex, so anything the child does that tries to obtain the same mutex, such as malloc, can deadlock.

Version-Release number of selected component (if applicable):
libvirt-v0.8.7-4.el6 (all existing RHEL libvirt releases)

How reproducible:
rare, found by code inspection rather than by an actual deadlock

Steps to Reproduce:
It may be possible to force the situation by using gdb to specifically block one thread inside malloc() then cause execution of another libvirt function that spawns a child process with an error that will trigger libvirt to use malloc() to try and report the error; however, I have not yet tried to construct such a test scenario.
  
Actual results:
Potential for deadlock.

Expected results:
Libvirt should obey the POSIX rules of only using async-signal-safe functions between fork and exec.

Additional info:
first brought up in this upstream thread:
https://www.redhat.com/archives/libvir-list/2011-January/msg01214.html