Re: [libvirt] Start of freeze for libvirt-0.9.7 and availability of rc1
On Thu, Nov 03, 2011 at 06:19:25PM +0800, Daniel Veillard wrote: Thanks to everybody who provided feedback and patches on rc1, I have made an rc2 available at ftp://libvirt.org/libvirt/libvirt-0.9.7-rc2.tar.gz there is also the rpms rebuilds for Fedora 14. I've discovered a problem with the file descriptor passing code we added to the remote protocol. Becaused the gnulib passfd() / recvfd() functions secretly send a single byte of data, as well as the FD, we need to handle EAGAIN when sending or receiving. Currently we don't, so when passing FDs we randomly get EAGAIN and the client connection gets killed off. Fixing this might require an RPC protocol change, which should obviously be done before the final release. 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Start of freeze for libvirt-0.9.7 and availability of rc1
Thanks to everybody who provided feedback and patches on rc1, I have made an rc2 available at ftp://libvirt.org/libvirt/libvirt-0.9.7-rc2.tar.gz there is also the rpms rebuilds for Fedora 14. One think I noted while the rpm was building is the following warnings: CCLD libvirt_test.la *** Warning: Linking the shared library libvirt_test.la against the non-libtool *** objects probes.o is not portable! *** Warning: Linking the shared library libvirt.la against the non-libtool *** objects probes.o is not portable! CCLD libvirt-qemu.la I also get *** Warning: Linking the shared library libvirt.la against the non-libtool *** objects probes.o is not portable! when I build from the tree. I assume it's related to src/Makefile.am if WITH_DTRACE libvirt_la_BUILT_LIBADD += probes.o and maybe it expects some .lo instead, but I'm not sure how to tweak this correctly :) Anyway, please check that rc2 too. Eric do you think you will be able to fix the missing 'ptsname_r' in gnulib in time or should we make a small workaround for platforms lacking it for the release ? Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Start of freeze for libvirt-0.9.7 and availability of rc1
On Thu, Nov 03, 2011 at 06:19:25PM +0800, Daniel Veillard wrote: Thanks to everybody who provided feedback and patches on rc1, I have made an rc2 available at ftp://libvirt.org/libvirt/libvirt-0.9.7-rc2.tar.gz there is also the rpms rebuilds for Fedora 14. One think I noted while the rpm was building is the following warnings: CCLD libvirt_test.la *** Warning: Linking the shared library libvirt_test.la against the non-libtool *** objects probes.o is not portable! *** Warning: Linking the shared library libvirt.la against the non-libtool *** objects probes.o is not portable! CCLD libvirt-qemu.la I also get *** Warning: Linking the shared library libvirt.la against the non-libtool *** objects probes.o is not portable! when I build from the tree. I assume it's related to src/Makefile.am if WITH_DTRACE libvirt_la_BUILT_LIBADD += probes.o and maybe it expects some .lo instead, but I'm not sure how to tweak this correctly :) This is just libtool getting annoyed that it didn't create the .o file itself - it is created directly by dtrace, so there is no .lo file. There is no actual problem here. 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Start of freeze for libvirt-0.9.7 and availability of rc1
On Thu, Nov 03, 2011 at 06:19:25PM +0800, Daniel Veillard wrote: Thanks to everybody who provided feedback and patches on rc1, I have made an rc2 available at ftp://libvirt.org/libvirt/libvirt-0.9.7-rc2.tar.gz there is also the rpms rebuilds for Fedora 14. Builds fine now on Debian: https://buildd.debian.org/status/package.php?p=libvirtsuite=experimental packages will be available with the next mirror pulse. Cheers, -- Guido -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Start of freeze for libvirt-0.9.7 and availability of rc1
On Mon, Oct 31, 2011 at 05:51:55PM +0800, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.7 .
We may make an exception for patch set which got a few round of reviews
though, like Stefan's ones (v4 IIRC), and anything which we know may
need fixing in the API before the release.
I have made a release candidate 1 tarball (and associated rpms) at
ftp://libvirt.org/libvirt/libvirt-0.9.7-rc1.tar.gz
I think I will make an rc2 on Wed or Thu and then try to
make the release around Friday of the end of the week if things
looks good.
Please give it a try !
Built fine on most Debian architectures:
https://buildd.debian.org/status/package.php?p=libvirtsuite=experimental
The built failure on amd64 is due to virnetsockettest failing with:
5) Socket UNIX Accept... libvir: RPC error : Path
/build/buildd-libvirt_0.9.7~rc1-1-amd64-EGXZTE/libvirt-0.9.7~rc1/debian/build/tests/virnetsockettest-test.sock
too long for unix socket: Cannot allocate memory
since the socket path doesn't fit in UNIX_PATH_MAX. Since exceeding the
path shouldn't't be fatal I'm using the attached patch.
Cheers,
-- Guido
From: =?UTF-8?q?Guido=20G=C3=BCnther?= a...@sigxcpu.org
Date: Wed, 2 Nov 2011 19:02:42 +0100
Subject: Skip socket test if we exceed UNIX_PATH_MAX.
As seen on the amd64 buildd with:
5) Socket UNIX Accept... libvir: RPC error : Path /build/buildd-libvirt_0.9.7~rc1-1-amd64-EGXZTE/libvirt-0.9.7~rc1/debian/build/tests/virnetsockettest-test.sock too long for unix socket: Cannot allocate memory
---
tests/virnetsockettest.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/tests/virnetsockettest.c b/tests/virnetsockettest.c
index 1b88605..d7c0c4f 100644
--- a/tests/virnetsockettest.c
+++ b/tests/virnetsockettest.c
@@ -205,11 +205,13 @@ static int testSocketUNIXAccept(const void *data ATTRIBUTE_UNUSED)
if (progname[0] == '/') {
if (virAsprintf(path, %s-test.sock, progname) 0) {
virReportOOMError();
+ret = EXIT_AM_SKIP;
goto cleanup;
}
} else {
if (virAsprintf(path, %s/%s-test.sock, abs_builddir, progname) 0) {
virReportOOMError();
+ret = EXIT_AM_SKIP;
goto cleanup;
}
}
@@ -254,11 +256,13 @@ static int testSocketUNIXAddrs(const void *data ATTRIBUTE_UNUSED)
if (progname[0] == '/') {
if (virAsprintf(path, %s-test.sock, progname) 0) {
virReportOOMError();
+ret = EXIT_AM_SKIP;
goto cleanup;
}
} else {
if (virAsprintf(path, %s/%s-test.sock, abs_builddir, progname) 0) {
virReportOOMError();
+ret = EXIT_AM_SKIP;
goto cleanup;
}
}
--
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Start of freeze for libvirt-0.9.7 and availability of rc1
On 11/02/2011 12:57 PM, Guido Günther wrote:
Built fine on most Debian architectures:
https://buildd.debian.org/status/package.php?p=libvirtsuite=experimental
The built failure on amd64 is due to virnetsockettest failing with:
5) Socket UNIX Accept... libvir: RPC error : Path
/build/buildd-libvirt_0.9.7~rc1-1-amd64-EGXZTE/libvirt-0.9.7~rc1/debian/build/tests/virnetsockettest-test.sock
too long for unix socket: Cannot allocate memory
since the socket path doesn't fit in UNIX_PATH_MAX. Since exceeding the
path shouldn't't be fatal I'm using the attached patch.
From: =?UTF-8?q?Guido=20G=C3=BCnther?=a...@sigxcpu.org
Date: Wed, 2 Nov 2011 19:02:42 +0100
Subject: Skip socket test if we exceed UNIX_PATH_MAX.
As seen on the amd64 buildd with:
s/buildd/build/
+++ b/tests/virnetsockettest.c
@@ -205,11 +205,13 @@ static int testSocketUNIXAccept(const void *data
ATTRIBUTE_UNUSED)
if (progname[0] == '/') {
if (virAsprintf(path, %s-test.sock, progname) 0) {
virReportOOMError();
+ret = EXIT_AM_SKIP;
goto cleanup;
}
Wrong place to be checking - virAsprintf() only fails on OOM (malloc
failure), not on size fit, so your skip is unlikely to be hit. I agree
that it's okay to skip the test if run in a subdirectory so deep that a
Unix socket cannot be created with a name that long, but that should be
done strlen() check just before virNetSocketNewListenUNIX, not by
looking for malloc failure. And since we're most likely not out of
memory, that may mean we also have a bug to fix in our error reporting
quality within virNetSocketNewListenUNIX.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Start of freeze for libvirt-0.9.7 and availability of rc1
On 11/02/2011 02:57 PM, Guido Günther wrote:
On Mon, Oct 31, 2011 at 05:51:55PM +0800, Daniel Veillard wrote:
We are now entering the freeze for libvirt-0.9.7 .
We may make an exception for patch set which got a few round of reviews
though, like Stefan's ones (v4 IIRC), and anything which we know may
need fixing in the API before the release.
I have made a release candidate 1 tarball (and associated rpms) at
ftp://libvirt.org/libvirt/libvirt-0.9.7-rc1.tar.gz
I think I will make an rc2 on Wed or Thu and then try to
make the release around Friday of the end of the week if things
looks good.
Please give it a try !
Built fine on most Debian architectures:
https://buildd.debian.org/status/package.php?p=libvirtsuite=experimental
The built failure on amd64 is due to virnetsockettest failing with:
5) Socket UNIX Accept... libvir: RPC error : Path
/build/buildd-libvirt_0.9.7~rc1-1-amd64-EGXZTE/libvirt-0.9.7~rc1/debian/build/tests/virnetsockettest-test.sock
too long for unix socket: Cannot allocate memory
since the socket path doesn't fit in UNIX_PATH_MAX. Since exceeding the
path shouldn't't be fatal I'm using the attached patch.
Cheers,
-- Guido
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
From: =?UTF-8?q?Guido=20G=C3=BCnther?= a...@sigxcpu.org Date: Wed, 2
Nov 2011 19:02:42 +0100 Subject: Skip socket test if we exceed
UNIX_PATH_MAX. As seen on the amd64 buildd with: 5) Socket UNIX
Accept... libvir: RPC error : Path
/build/buildd-libvirt_0.9.7~rc1-1-amd64-EGXZTE/libvirt-0.9.7~rc1/debian/build/tests/virnetsockettest-test.sock
too long for unix socket: Cannot allocate memory ---
tests/virnetsockettest.c | 4 1 files changed, 4 insertions(+), 0
deletions(-) diff --git a/tests/virnetsockettest.c
b/tests/virnetsockettest.c index 1b88605..d7c0c4f 100644 ---
a/tests/virnetsockettest.c +++ b/tests/virnetsockettest.c @@ -205,11
+205,13 @@ static int testSocketUNIXAccept(const void *data
ATTRIBUTE_UNUSED) if (progname[0] == '/') { if (virAsprintf(path,
%s-test.sock, progname) 0) { virReportOOMError(); + ret =
EXIT_AM_SKIP; goto cleanup; } } else { if (virAsprintf(path,
%s/%s-test.sock, abs_builddir, progname) 0) {
virReportOOMError(); + ret = EXIT_AM_SKIP; goto cleanup; } } @@
-254,11 +256,13 @@ static int testSocketUNIXAddrs(const void *data
ATTRIBUTE_UNUSED) if (progname[0] == '/') { if (virAsprintf(path,
%s-test.sock, progname) 0) { virReportOOMError(); + ret =
EXIT_AM_SKIP; goto cleanup; } } else { if (virAsprintf(path,
%s/%s-test.sock, abs_builddir, progname) 0) {
virReportOOMError(); + ret = EXIT_AM_SKIP; goto cleanup; } } --
This patch is not correct. The code is failing further below when
calling virNetSocketNewListenUNIX. I am surprised if this makes it work
for your test env since it shouldn't run out of memory there.
The problem is obviously that the path exceeds 108 (UNIX_PATH_MAX)
characters, the max. for the UnixIO socket path. The solution may either
be to fall back to a path in /tmp (but why not do this always then) or
to cut down the progname + abs_builddir pair to a max of ~97 chars or to
try to build in a shorter path...
Maybe the following one works:
diff --git a/tests/virnetsockettest.c b/tests/virnetsockettest.c
index 6320ce0..b5c14a1 100644
--- a/tests/virnetsockettest.c
+++ b/tests/virnetsockettest.c
@@ -25,6 +25,9 @@
#ifdef HAVE_IFADDRS_H
# include ifaddrs.h
#endif
+#ifndef WIN32
+# include sys/un.h
+#endif
#include testutils.h
#include util.h
@@ -200,6 +203,8 @@ static int testSocketUNIXAccept(const void *data
ATTRIBUTE_UNUSED)
virNetSocketPtr ssock = NULL; /* Server socket */
virNetSocketPtr csock = NULL; /* Client socket */
int ret = -1;
+int tmpfd = -1;
+struct sockaddr_un sun;
char *path;
if (progname[0] == '/') {
@@ -214,6 +219,19 @@ static int testSocketUNIXAccept(const void *data
ATTRIBUTE_UNUSED)
}
}
+if (strlen(path) = sizeof(sun.sun_path)) {
+if (!virStrcpy(path, /tmp/test.sock.XX,
sizeof(sun.sun_path))) {
+VIR_DEBUG(Unexpected error using virStrcpyStatic);
+goto cleanup;
+}
+tmpfd = mkostemp(path, 0700);
+if (tmpfd 0) {
+virReportSystemError(errno, %s,
+ _(Failed to create temporary file));
+goto cleanup;
+}
+}
+
if (virNetSocketNewListenUNIX(path, 0700, -1, getgid(), lsock) 0)
goto cleanup;
@@ -236,6 +254,10 @@ static int testSocketUNIXAccept(const void *data
ATTRIBUTE_UNUSED)
ret = 0;
cleanup:
+if (tmpfd = 0) {
+unlink(path);
+VIR_FORCE_CLOSE(tmpfd);
+}
VIR_FREE(path);
virNetSocketFree(lsock);
virNetSocketFree(ssock);
@@ -249,6 +271,8 @@ static int testSocketUNIXAddrs(const void *data
ATTRIBUTE_UNUSED)
virNetSocketPtr ssock = NULL; /* Server socket */
virNetSocketPtr csock = NULL; /*
Re: [libvirt] Start of freeze for libvirt-0.9.7 and availability of rc1
On Wed, Nov 02, 2011 at 02:19:07PM -0600, Eric Blake wrote:
On 11/02/2011 12:57 PM, Guido Günther wrote:
Built fine on most Debian architectures:
https://buildd.debian.org/status/package.php?p=libvirtsuite=experimental
The built failure on amd64 is due to virnetsockettest failing with:
5) Socket UNIX Accept... libvir: RPC error : Path
/build/buildd-libvirt_0.9.7~rc1-1-amd64-EGXZTE/libvirt-0.9.7~rc1/debian/build/tests/virnetsockettest-test.sock
too long for unix socket: Cannot allocate memory
since the socket path doesn't fit in UNIX_PATH_MAX. Since exceeding the
path shouldn't't be fatal I'm using the attached patch.
From: =?UTF-8?q?Guido=20G=C3=BCnther?=a...@sigxcpu.org
Date: Wed, 2 Nov 2011 19:02:42 +0100
Subject: Skip socket test if we exceed UNIX_PATH_MAX.
As seen on the amd64 buildd with:
s/buildd/build/
This one was actually intentional. It's the build daemon, short buildd.
+++ b/tests/virnetsockettest.c
@@ -205,11 +205,13 @@ static int testSocketUNIXAccept(const void *data
ATTRIBUTE_UNUSED)
if (progname[0] == '/') {
if (virAsprintf(path, %s-test.sock, progname) 0) {
virReportOOMError();
+ret = EXIT_AM_SKIP;
goto cleanup;
}
Wrong place to be checking - virAsprintf() only fails on OOM (malloc
failure), not on size fit, so your skip is unlikely to be hit. I
agree that it's okay to skip the test if run in a subdirectory so
deep that a Unix socket cannot be created with a name that long, but
that should be done strlen() check just before
virNetSocketNewListenUNIX, not by looking for malloc failure. And
since we're most likely not out of memory, that may mean we also
have a bug to fix in our error reporting quality within
virNetSocketNewListenUNIX.
Yes - the analysis was correct, the patch was horribly broken though.
New versions attached. I wen't for a tempdir though to make sure the
test can succeed.
-- Guido
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
