In the error path, the test buffer is free'd, but due to how the free
routine is written the 'test' buffer pointer does not return to the caller
as NULL and then the free'd buffer address is returned to the caller.

The  virDomainObj, qemuAgent, qemuMonitor, lxcMonitor classes
all require a mutex, so can be switched to use virObjectLockable
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

qemumonitorjsontest creates a temporary directory to hold the socket
that is simulating the monitor socket. The directory containing the
socket wasn't disposed properly at the end of the test leaving garbage
in the temporary folder.

When doing the qemumonitorjsontest on a machine under heavy load the
test tends to deadlock from time to time. This patch adds the hack to
break the event loop that is used in virsh.

to avoid ENAMETOOLONG:

https://buildd.debian.org/status/fetch.php?pkg=libvirt&arch=amd64&ver=1.0.0~rc1-1&stamp=1351453521

https://www.gnu.org/licenses/gpl-howto.html recommends that
the 'If not, see <url>.' phrase be a separate sentence.

* tests/securityselinuxhelper.c: Remove doubled line.
* tests/securityselinuxtest.c: Likewise.
* globally: s/;  If/.  If/

Technically speaking we should wait until we receive the QMP
greeting message before attempting to send any QMP monitor
commands. Mostly we've got away with this, but there is a race
in some QEMU which cause it to SEGV if you sent it data too
soon after startup. Waiting for the QMP greeting avoids the
race
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

To be able to test the QEMU monitor code, we need to have a fake
QEMU monitor server. This introduces a simple (dumb) framework
that can do this. The test case registers a series of items to
be sent back as replies to commands that will be executed. A
thread runs the event loop looking for incoming replies and
sending back this pre-registered data. This allows testing all
QEMU monitor code that deals with parsing responses and errors
from QEMU, without needing QEMU around
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>