Commit 93ec384 was tested on mingw, but broke the build on Linux:
CCLD shunloadtest
shunloadtest.o: In function `main':
/home/eblake/libvirt/tests/shunloadtest.c:106: undefined reference to `virFilePrintf'
...
ssh.o: In function `main':
/home/eblake/libvirt/tests/ssh.c:43: undefined reference to `virFilePrintf'
/home/eblake/libvirt/tests/ssh.c:49: undefined reference to `virFilePrintf'
* tests/testutils.h (fprintf): Provide escape hatch.
* tests/shunloadtest.c: Use it.
* tests/ssh.c: Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
The shunloadStart function didn't check the status of virInitialize which
was flagged by Coverity. Adjust the function and shunloadtest in order
to handle the situation.
https://www.gnu.org/licenses/gpl-howto.html recommends that
the 'If not, see <url>.' phrase be a separate sentence.
* tests/securityselinuxhelper.c: Remove doubled line.
* tests/securityselinuxtest.c: Likewise.
* globally: s/; If/. If/
Per the FSF address could be changed from time to time, and GNU
recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html)
You should have received a copy of the GNU General Public License
along with Foobar. If not, see <http://www.gnu.org/licenses/>.
This patch removes the explicit FSF address, and uses above instead
(of course, with inserting 'Lesser' before 'General').
Except a bunch of files for security driver, all others are changed
automatically, the copyright for securify files are not complete,
that's why to do it manually:
src/security/security_selinux.h
src/security/security_driver.h
src/security/security_selinux.c
src/security/security_apparmor.h
src/security/security_apparmor.c
src/security/security_driver.c
For unknown reasons, the shunloadtest will crash on Fedora 16
inside dlopen()
(gdb) bt
#0 0x00000000000050e6 in ?? ()
#1 0x00007ff61a77b9d5 in floor () from /lib64/libm.so.6
#2 0x00007ff61e522963 in _dl_relocate_object () from /lib64/ld-linux-x86-64.so.2
#3 0x00007ff61e5297e6 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#4 0x00007ff61e525006 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#5 0x00007ff61e52917a in _dl_open () from /lib64/ld-linux-x86-64.so.2
#6 0x00007ff61e0f6f26 in dlopen_doit () from /lib64/libdl.so.2
#7 0x00007ff61e525006 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#8 0x00007ff61e0f752f in _dlerror_run () from /lib64/libdl.so.2
#9 0x00007ff61e0f6fc1 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2
#10 0x0000000000400a15 in main (argc=<optimized out>, argv=<optimized out>) at shunloadtest.c:105
Changing from RTLD_NOW to RTLD_LAZY avoids this problem,
but quite possibly does not fix the root cause.
* shunloadtest.c: s/NOW/LAZY/
When libvirt calls virInitialize it creates a thread local
for the virErrorPtr storage, and registers a callback to
cleanup memory when a thread exits. When libvirt is dlclose()d
or otherwise made non-resident, the callback function is
removed from memory, but the thread local may still exist
and if a thread later exists, it will invoke the callback
and SEGV. There may also be other thread locals with callbacks
pointing to libvirt code, so it is in general never safe to
unload libvirt.so from memory once initialized.
To allow dlclose() to succeed, but keep libvirt.so resident
in memory, link with '-z nodelete'. This issue was first
found with the libvirt CIM provider, but can potentially
hit many of the dynamic language bindings which all ultimately
involve dlopen() in some way, either on libvirt.so itself,
or on the glue code for the binding which in turns links
to libvirt
* configure.ac, src/Makefile.am: Ensure libvirt.so is linked
with -z nodelete
* cfg.mk, .gitignore, tests/Makefile.am, tests/shunloadhelper.c,
tests/shunloadtest.c: A test case to unload libvirt while
a thread is still running.
Martin Kletzander