[libvirt] [PATCH] Make locking more debuggable from logs

Daniel P. Berrange berrange at redhat.com
Mon Jul 22 13:58:14 UTC 2013


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 at 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 :|




More information about the libvir-list mailing list