Re: [libvirt] [PATCH] win32: Properly handle TlsGetValue returning NULL
Am 22. April 2012 04:32 schrieb Eric Blake ebl...@redhat.com: On 04/21/2012 11:11 AM, Matthias Bolte wrote: virThreadSelf tries to access the virThreadPtr stored in TLS for the current thread via TlsGetValue. When virThreadSelf is called on a thread that was not created via virThreadCreate (e.g. the main thread) then TlsGetValue returns NULL as TlsAlloc initializes TLS slots to NULL. virThreadSelf can be called on the main thread via this call chain from virsh vshDeinit virEventAddTimeout virEventPollAddTimeout virEventPollInterruptLocked virThreadIsSelf triggering a segfault as virThreadSelf unconditionally dereferences the return value of TlsGetValue. Fix this by making virThreadSelf check the TLS slot value for NULL and setting the given virThreadPtr accordingly. Reported by Marcel Müller. --- src/util/threads-win32.c | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) ACK. Thanks, pushed. -- Matthias Bolte http://photron.blogspot.com -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] vbox: Fix passing an empty IMedium* array to IMachine::Delete
vboxArray is not castable to a COM item type. vboxArray is a
wrapper around the XPCOM and MSCOM specific array handling.
In this case we can avoid passing NULL as an empty array to
IMachine::Delete by passing a dummy IMedium* array with a single
NULL item.
---
Jean-Baptiste, I can not reproduce the assertion you mentioned, or
I don't know where to look for it. So could you verify that is patch
avoids this assertion?
src/vbox/vbox_tmpl.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/vbox/vbox_tmpl.c b/src/vbox/vbox_tmpl.c
index 57c18a4..4b0ee2e 100644
--- a/src/vbox/vbox_tmpl.c
+++ b/src/vbox/vbox_tmpl.c
@@ -5294,11 +5294,10 @@ vboxDomainUndefineFlags(virDomainPtr dom, unsigned int
flags)
((IMachine_Delete)machine-vtbl-Delete)(machine, safeArray,
progress);
# else
-union {
-vboxArray array;
-IMedium *medium;
-} u = { .array = VBOX_ARRAY_INITIALIZER };
-machine-vtbl-Delete(machine, 0, u.medium, progress);
+/* XPCOM doesn't like NULL as an array, even when the array size is 0.
+ * Instead pass it a dummy array to avoid passing NULL. */
+IMedium *array[] = { NULL };
+machine-vtbl-Delete(machine, 0, array, progress);
# endif
if (progress != NULL) {
progress-vtbl-WaitForCompletion(progress, -1);
--
1.7.4.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] building: remove libvirt_dbus.syms from EXTRA_DIST
On 04/20/2012 11:10 AM, Osier Yang wrote: On 2012年04月20日 11:05, Wen Congyang wrote: commit 2223ea98 removes src/libvirt_dbus.syms, but it forgets to remove it from EXTRA_DIST. It will cause 'make dist' failed. --- src/Makefile.am | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index b8a19b4..e48dfa5 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1230,7 +1230,6 @@ EXTRA_DIST += \ libvirt_driver_modules.syms \ libvirt_daemon.syms \ libvirt_linux.syms \ - libvirt_dbus.syms \ libvirt_network.syms \ libvirt_nwfilter.syms \ libvirt_sasl.syms \ ACK Thanks, pushed. Wen Congyang Osier -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] udevadm settle can take too long
Hi,
http://bugs.debian.org/663931 is a bug I'm hitting, where virt-manager
times out on the initial connection to libvirt.
The basic problem is that, while checking storage volumes,
virt-manager causes libvirt to call udevadm settle. There's an
interaction where libvirt's earlier use of network namespaces (to probe
LXC features) had caused some uevents to be sent that get filtered out
before they reach udev. This confuses udevadm settle a bit, and so
it sits there waiting for a 2-3 minute built-in timeout before returning.
Eventually libvirtd prints:
2012-04-22 18:22:18.678+: 30503: warning : virKeepAliveTimer:182 : No
response from client 0x7feec4003630 after 5 keepalive messages in 30 seconds
and virt-manager prints:
2012-04-22 18:22:18.931+: 30647: warning : virKeepAliveSend:128 : Failed
to send keepalive response to client 0x25004e0
and the connection gets dropped.
One workaround could be to specify a shorter timeout when doing the
settle. The patch appended below allows virt-manager to work,
although the connection still has to wait for the 10 second timeout
before it succeeds. I don't know what a better solution would be,
though. It seems the udevadm behavior might not be considered a bug
from the udev/kernel point of view:
https://lkml.org/lkml/2012/4/22/60
I'm using Linux 3.2.14 with libvirt 0.9.11. You can trigger the
udevadm issue using a program I posted at the Debian bug report link
above.
-jim
From 17e5b9ebab76acb0d711e8bc308023372fbc4180 Mon Sep 17 00:00:00 2001
From: Jim Paris j...@jtan.com
Date: Sun, 22 Apr 2012 14:35:47 -0400
Subject: [PATCH] shorten udevadmin settle timeout
Otherwise, udevadmin settle can take so long that connections from
e.g. virt-manager will get closed.
---
src/util/util.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/util/util.c b/src/util/util.c
index 6e041d6..dfe458e 100644
--- a/src/util/util.c
+++ b/src/util/util.c
@@ -2593,9 +2593,9 @@ virFileFindMountPoint(const char *type ATTRIBUTE_UNUSED)
void virFileWaitForDevices(void)
{
# ifdef UDEVADM
-const char *const settleprog[] = { UDEVADM, settle, NULL };
+const char *const settleprog[] = { UDEVADM, settle, --timeout, 10,
NULL };
# else
-const char *const settleprog[] = { UDEVSETTLE, NULL };
+const char *const settleprog[] = { UDEVSETTLE, --timeout, 10, NULL };
# endif
int exitstatus;
--
1.7.7
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
