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@xxxxxxxxxx> 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list