On 09/01/2011 10:57 AM, Daniel P. Berrange wrote:
+++ b/src/Makefile.am
@@ -1228,7 +1228,7 @@ libvirt_qemu.def: $(srcdir)/libvirt_qemu.syms
libvirt_la_SOURCES =
libvirt_la_LDFLAGS = $(VERSION_SCRIPT_FLAGS)$(LIBVIRT_SYMBOL_FILE) \
-version-info $(LIBVIRT_VERSION_INFO) \
- $(AM_LDFLAGS) \
+ $(AM_LDFLAGS) $(LIBVIRT_NODELETE) \
I would have listed this before $(AM_LDFLAGS), closer to the
$(LIBVIRT_VERSION_INFO) linker flags.
@@ -41,3 +42,5 @@ xencapstest
xmconfigtest
xml2sexprtest
xml2vmxtest
+libshunload.la
+shunloadtest
./autogen.sh will end up trying to sort these lines, causing a spurious
change for everyone else if you don't commit it sorted in the first place.
+
+/*
+ * When libvirt initializes, it creates a thread local for storing
+ * the last virErrorPtr instance. It also registers a cleanup
+ * callback for the thread local that will be invoked whenever
+ * a thread exits.
+ *
+ * If the libvirt.so library was dlopen()'d and is dlclose()'d
+ * while there is still a thread present, then when that thread
+ * later exits, the libvirt cleanup callback will be invoked.
+ * Unfortunately libvirt.so will no longer be in memory so the
+ * callback SEGVs (if you're lucky), or invokes unlreated
+ * code at the same address as the old callback (in you're
s/in/if/
+ * unlucky).
+ *
+ * To fix the problem libvirt is linked '-z nodelete' which
+ * prevents the code being removed from memory at dlclose().
It's a shame that dlclose() doesn't interact nicely with threads. But I
agree that making libvirt stay resident works around the problem, and is
the best we can do without some better, future, standardized interfaces
for more nicely dealing with interactions between shared modules and
threads.
+
+ /* If we got to hear the thread succesfully exited without
+ * causing a SEGV !
s/hear/here/; s/succesfully/successfully/
ACK with nits fixed.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org