On Mon, May 09, 2011 at 04:04:41PM +0200, Matthias Bolte wrote:
2011/5/9 Jiri Denemark <jdenemar@redhat.com>:
virsh didn't call virInitialize(), which (among other things) initializes virLastErr thread local variable. As a result of that, virsh could just segfault in virEventRegisterDefaultImpl() since that is the first call that touches (resets) virLastErr.
I have no idea what lucky coincidence made this bug visible but I was able to reproduce it in 100% cases but only in one specific environment which included building in sandbox.
Well, actually all public API that can be called as the first public API function ever called in a sound program calls virInitialize first internally. For example virConnectOpen. The documentation of virInitialize suggest to call it first, but doesn't require it.
A fix in line with the current behavior would be to make virEventRegisterDefaultImpl and virEventRunDefaultImpl call virInitialize first too.
Yep that's good.
But this doesn't fix another problem, a program could call virDomainFree(NULL) for some reason as the first public API call ever made in the process and libvirt would try to report an error but would segfault because of calling virResetLastError before virInitialize was called.
IMHO that would be a mis-use of the API because they should call virInitialize.
So you found a much bigger problem and I'm not sure about the correct general solution. We could make calling virInitialize first mandatory but that might break existing applications. Or we make all public API functions call virInitialize first.
I think we could just clarify the docs "Calling virInitialize is mandatory, unless your first API call is one of virConnectOpen* virEventRegisterDefaultImpl" 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 :|