On Mon, Jul 22, 2013 at 03:44:04PM +0200, Martin Kletzander wrote:
With this patch, there is new ./configure option
'--enable-lock-debug'
which controls whether we want to turn on debugging locks. This
feature is exposed as a ./configure option due to its huge overhead in
speed/log size and is only meant to be used with this in mind. It is
designed in a way that even log from deadlocked daemon should provide
enough info to find the deadlock itself. Every matching Lock() call
can be matched with its Unlock() call and with every Lock() called it
is visible whether it failed or not. Unlock() call follows the same
output, even though unnecessary (the call cannot block).
Lock logging is disabled while logging because that would either
recurse or deadlock.
Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com>
I'm really inclined to say that anyone wanting todo lock debugging
should just use systemtap / dtrace todo it, since it is better in
every way. You don't need any special compile options to enable
it, tracing scripts have little impact on operation of the program
being debugged, you can trivially filter data output so that it
only reports locking of specific objects, you can trace and
synchronize across processes and languages & kernel/userspace.
So I don't really think there is any compelling reason to include
lock debugging code in libvirt.
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|