[libvirt] Start of freeze for libvirt-0.9.4 and availability of rc1
As plannned we are entering the freeze for libvirt-0.9.4 . I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.4-rc1.tar.gz This seems to pass my minimal tests without problems, but please give it a try too and report problems, I will probably make an rc2 on Thursday or Friday, and then the final release next Monday or Tuesday, thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
于 2011年07月26日 14:48, Daniel Veillard 写道:
As plannned we are entering the freeze for libvirt-0.9.4 . I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.4-rc1.tar.gz
This seems to pass my minimal tests without problems, but please give it a try too and report problems,
I will probably make an rc2 on Thursday or Friday, and then the final release next Monday or Tuesday,
thanks !
Daniel
"make check" failed. # VIR_TEST_DEBUG=1 ./qemuxml2argvtest .................... 135) QEMU XML-2-ARGV cpu-topology2 ... libvir: error : internal error Child process (LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /home/osier/work/tar/libvirt-0.9.4/tests/qemuxml2argvdata/./qemu.sh -cpu ?) status unexpected: exit status 1 FAILED 136) QEMU XML-2-ARGV cpu-topology3 ... OK 137) QEMU XML-2-ARGV cpu-minimum1 ... libvir: error : internal error Child process (LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /home/osier/work/tar/libvirt-0.9.4/tests/qemuxml2argvdata/./qemu.sh -cpu ?) status unexpected: exit status 1 FAILED 138) QEMU XML-2-ARGV cpu-minimum2 ... libvir: error : internal error Child process (LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /home/osier/work/tar/libvirt-0.9.4/tests/qemuxml2argvdata/./qemu.sh -cpu ?) status unexpected: exit status 1 FAILED 139) QEMU XML-2-ARGV cpu-exact1 ... libvir: error : internal error Child process (LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /home/osier/work/tar/libvirt-0.9.4/tests/qemuxml2argvdata/./qemu.sh -cpu ?) status unexpected: exit status 1 FAILED 140) QEMU XML-2-ARGV cpu-exact2 ... libvir: error : internal error Child process (LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /home/osier/work/tar/libvirt-0.9.4/tests/qemuxml2argvdata/./qemu.sh -cpu ?) status unexpected: exit status 1 FAILED 141) QEMU XML-2-ARGV cpu-strict1 ... libvir: error : internal error Child process (LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /home/osier/work/tar/libvirt-0.9.4/tests/qemuxml2argvdata/./qemu.sh -cpu ?) status unexpected: exit status 1 FAILED Part of the debug log: 141) QEMU XML-2-ARGV cpu-strict1 ... 16:53:50.554: 24630: debug : virCommandRunAsync:2040 : About to run LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /home/osier/work/tar/libvirt-0.9.4/tests/qemuxml2argvdata/./qemu.sh -M ? 16:53:50.555: 24630: debug : virCommandRunAsync:2056 : Command result 0, with PID 24645 16:53:50.556: 24630: debug : virCommandRun:1862 : Result exit status 1, stdout: '' stderr: '16:53:50.555: 24645: debug : virCommandHook:1959 : Hook is done 0 libvir: error : cannot execute binary /home/osier/work/tar/libvirt-0.9.4/tests/qemuxml2argvdata/./qemu.sh: Permission denied Command works well in Bash. [root@Osier libvirt-0.9.4]# LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /home/osier/work/tar/libvirt-0.9.4/tests/qemuxml2argvdata/./qemu.sh -M ? pc Still looking. Osier
On Tue, Jul 26, 2011 at 05:02:49PM +0800, Osier Yang wrote:
于 2011年07月26日 14:48, Daniel Veillard 写道:
As plannned we are entering the freeze for libvirt-0.9.4 . I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.4-rc1.tar.gz
This seems to pass my minimal tests without problems, but please give it a try too and report problems,
I will probably make an rc2 on Thursday or Friday, and then the final release next Monday or Tuesday,
thanks !
Daniel
"make check" failed.
# VIR_TEST_DEBUG=1 ./qemuxml2argvtest ....................
135) QEMU XML-2-ARGV cpu-topology2 ... libvir: error : internal error Child process (LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /home/osier/work/tar/libvirt-0.9.4/tests/qemuxml2argvdata/./qemu.sh -cpu ?) status unexpected: exit status 1 FAILED [...] 141) QEMU XML-2-ARGV cpu-strict1 ... 16:53:50.554: 24630: debug : virCommandRunAsync:2040 : About to run LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /home/osier/work/tar/libvirt-0.9.4/tests/qemuxml2argvdata/./qemu.sh -M ? 16:53:50.555: 24630: debug : virCommandRunAsync:2056 : Command result 0, with PID 24645 16:53:50.556: 24630: debug : virCommandRun:1862 : Result exit status 1, stdout: '' stderr: '16:53:50.555: 24645: debug : virCommandHook:1959 : Hook is done 0 libvir: error : cannot execute binary /home/osier/work/tar/libvirt-0.9.4/tests/qemuxml2argvdata/./qemu.sh: Permission denied
Command works well in Bash.
weird ... I don't think we changed this for ages ... I just tried this locally and could not reproduce this (./configure --prefix=/usr ; make ; make check ...) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Tue, Jul 26, 2011 at 08:48, Daniel Veillard <veillard@redhat.com> wrote:
As plannned we are entering the freeze for libvirt-0.9.4 . I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.4-rc1.tar.gz
This seems to pass my minimal tests without problems, but please give it a try too and report problems,
I will probably make an rc2 on Thursday or Friday, and then the final release next Monday or Tuesday,
thanks !
This fails on F-13 with: /bin/sh ../libtool --silent --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../gnulib/lib -I../gnulib/lib -I../include -I../src/util -I../include -DIN_LIBVIRT -I../src/conf -I/usr/include/libxml2 -Wall -W -Wformat-y2k -Wformat-security -Winit-self -Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wlogical-op -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wvolatile-register-var -Wdisabled-optimization -Wbuiltin-macro-redefined -Wmudflap -Wpacked-bitfield-compat -Wsync-nand -Wattributes -Wcoverage-mismatch -Wmultichar -Wno-missing-field-initializers -Wno-sign-compare -Wframe-larger-than=4096 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-all --param=ssp-buffer-size=4 -fexceptions -fasynchronous-unwind-tables -fdiagnostics-show-option -funit-at-a-time -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c -o libvirt_driver_qemu_la-qemu_command.lo `test -f 'qemu/qemu_command.c' || echo './'`qemu/qemu_command.c In file included from qemu/qemu_command.c:40: ./network/bridge_driver.h:58:4: error: invalid preprocessing directive #defing
Introduced by commit 239322cb, reported by Ruben Kerkhof. --- src/network/bridge_driver.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/network/bridge_driver.h b/src/network/bridge_driver.h index 518a5ba..4913126 100644 --- a/src/network/bridge_driver.h +++ b/src/network/bridge_driver.h @@ -55,7 +55,7 @@ int networkBuildDhcpDaemonCommandLine(virNetworkObjPtr network, # define networkAllocateActualDevice(iface) 0 # define networkNotifyActualDevice(iface) 0 # define networkReleaseActualDevice(iface) 0 -# defing networkGetNetworkAddress(netname, netaddr) (-2) +# define networkGetNetworkAddress(netname, netaddr) (-2) # define networkBuildDhcpDaemonCommandLine(network, cmdout, pidfile, dctx) 0 # endif -- 1.7.6
On Tue, Jul 26, 2011 at 08:25:10PM +0800, Osier Yang wrote:
Introduced by commit 239322cb, reported by Ruben Kerkhof. --- src/network/bridge_driver.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/network/bridge_driver.h b/src/network/bridge_driver.h index 518a5ba..4913126 100644 --- a/src/network/bridge_driver.h +++ b/src/network/bridge_driver.h @@ -55,7 +55,7 @@ int networkBuildDhcpDaemonCommandLine(virNetworkObjPtr network, # define networkAllocateActualDevice(iface) 0 # define networkNotifyActualDevice(iface) 0 # define networkReleaseActualDevice(iface) 0 -# defing networkGetNetworkAddress(netname, netaddr) (-2) +# define networkGetNetworkAddress(netname, netaddr) (-2) # define networkBuildDhcpDaemonCommandLine(network, cmdout, pidfile, dctx) 0 # endif
ACK 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 :|
于 2011年07月26日 19:51, Daniel P. Berrange 写道:
On Tue, Jul 26, 2011 at 08:25:10PM +0800, Osier Yang wrote:
Introduced by commit 239322cb, reported by Ruben Kerkhof. --- src/network/bridge_driver.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/network/bridge_driver.h b/src/network/bridge_driver.h index 518a5ba..4913126 100644 --- a/src/network/bridge_driver.h +++ b/src/network/bridge_driver.h @@ -55,7 +55,7 @@ int networkBuildDhcpDaemonCommandLine(virNetworkObjPtr network, # define networkAllocateActualDevice(iface) 0 # define networkNotifyActualDevice(iface) 0 # define networkReleaseActualDevice(iface) 0 -# defing networkGetNetworkAddress(netname, netaddr) (-2) +# define networkGetNetworkAddress(netname, netaddr) (-2) # define networkBuildDhcpDaemonCommandLine(network, cmdout, pidfile, dctx) 0 # endif
ACK
Daniel Thanks, pushed.
Osier
On Tue, Jul 26, 2011 at 01:02:21PM +0200, Ruben Kerkhof wrote:
On Tue, Jul 26, 2011 at 08:48, Daniel Veillard <veillard@redhat.com> wrote: This fails on F-13 with:
[...]
In file included from qemu/qemu_command.c:40: ./network/bridge_driver.h:58:4: error: invalid preprocessing directive #defing
Ah this was compiled without network in some ways Osier already fixed this in git, thanks for the report ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
I have this failure for bsd: rpc/virnetserver.c:786: error: 'virNetServer' has no member named 'mdns' gmake[3]: *** [libvirt_net_rpc_server_la-virnetserver.lo] Error 1 gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4' gmake: *** [all] Error 2 *** Error code 1
-jgh -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
On 07/26/2011 10:18 AM, Jason Helfman wrote:
I have this failure for bsd:
rpc/virnetserver.c:786: error: 'virNetServer' has no member named 'mdns' gmake[3]: *** [libvirt_net_rpc_server_la-virnetserver.lo] Error 1 gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4' gmake: *** [all] Error 2 *** Error code 1
Already fixed: https://www.redhat.com/archives/libvir-list/2011-July/msg01836.html -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Tue, Jul 26, 2011 at 10:24:57AM -0600, Eric Blake thus spake:
On 07/26/2011 10:18 AM, Jason Helfman wrote:
I have this failure for bsd:
rpc/virnetserver.c:786: error: 'virNetServer' has no member named 'mdns' gmake[3]: *** [libvirt_net_rpc_server_la-virnetserver.lo] Error 1 gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4' gmake: *** [all] Error 2 *** Error code 1
Already fixed: https://www.redhat.com/archives/libvir-list/2011-July/msg01836.html
Thanks! I have this error now, though. No difference between the tarball source and the git sources for this file. remote.c:1643: error: 'tmp' undeclared (first use in this function) gmake[3]: *** [libvirtd-remote.o] Error 1 gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4/daemon' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4/daemon' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4' gmake: *** [all] Error 2 *** Error code 1 Thanks, Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
On 07/26/2011 10:40 AM, Jason Helfman wrote:
Thanks! I have this error now, though. No difference between the tarball source and the git sources for this file.
remote.c:1643: error: 'tmp' undeclared (first use in this function) gmake[3]: *** [libvirtd-remote.o] Error 1
That's odd. Line 1643 is in remoteDispatchDomainGetBlockJobInfo, which unconditionally declares virDomainBlockJobInfo tmp at line 1631. I can't see why you would be running into a compilation error here; can you give us better details? -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Tue, Jul 26, 2011 at 11:45:19AM -0600, Eric Blake thus spake:
On 07/26/2011 10:40 AM, Jason Helfman wrote:
Thanks! I have this error now, though. No difference between the tarball source and the git sources for this file.
remote.c:1643: error: 'tmp' undeclared (first use in this function) gmake[3]: *** [libvirtd-remote.o] Error 1
That's odd. Line 1643 is in remoteDispatchDomainGetBlockJobInfo, which unconditionally declares virDomainBlockJobInfo tmp at line 1631. I can't see why you would be running into a compilation error here; can you give us better details?
remote.c: At top level: remote.c:409: error: negative width in bit-field '_gl_verify_error_if_negative' remote.c: In function 'remoteDispatchDomainGetBlockJobInfo': remote.c:1630: error: 'virDomainBlockJobInfo' undeclared (first use in this function) remote.c:1630: error: (Each undeclared identifier is reported only once remote.c:1630: error: for each function it appears in.) remote.c:1630: error: expected ';' before 'tmp' remote.c:1643: warning: implicit declaration of function 'virDomainGetBlockJobInfo' remote.c:1643: warning: nested extern declaration of 'virDomainGetBlockJobInfo' [-Wnested-externs] remote.c:1643: error: 'tmp' undeclared (first use in this function) gmake[3]: *** [libvirtd-remote.o] Error 1 gmake[3]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4/daemon' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4/daemon' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/jhelfman/ports/devel/libvirt/work/libvirt-0.9.4' gmake: *** [all] Error 2 *** Error code 1 -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
On 07/26/2011 12:16 PM, Jason Helfman wrote:
remote.c: At top level: remote.c:409: error: negative width in bit-field '_gl_verify_error_if_negative' remote.c: In function 'remoteDispatchDomainGetBlockJobInfo': remote.c:1630: error: 'virDomainBlockJobInfo' undeclared (first use in this function)
Ah. You're running into the same problem that has been previously reported of compiling against the stale installed libvirt.h instead of the just-built in-tree libvirt.h. Matthias had started a patch for that, but it never got finished. https://www.redhat.com/archives/libvir-list/2011-May/msg01926.html -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Tue, Jul 26, 2011 at 12:26:20PM -0600, Eric Blake thus spake:
On 07/26/2011 12:16 PM, Jason Helfman wrote:
remote.c: At top level: remote.c:409: error: negative width in bit-field '_gl_verify_error_if_negative' remote.c: In function 'remoteDispatchDomainGetBlockJobInfo': remote.c:1630: error: 'virDomainBlockJobInfo' undeclared (first use in this function)
Ah. You're running into the same problem that has been previously reported of compiling against the stale installed libvirt.h instead of the just-built in-tree libvirt.h.
Matthias had started a patch for that, but it never got finished.
https://www.redhat.com/archives/libvir-list/2011-May/msg01926.html
I de-installed the port, and then continued with the make process, and it installed just fine. What is the status of this patch? If this isn't going to make it into the release, I can warn users that this port needs to be de-installed prior to building the port. Thanks, Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
2011/7/26 Jason Helfman <jhelfman@e-e.com>:
On Tue, Jul 26, 2011 at 12:26:20PM -0600, Eric Blake thus spake:
On 07/26/2011 12:16 PM, Jason Helfman wrote:
remote.c: At top level: remote.c:409: error: negative width in bit-field '_gl_verify_error_if_negative' remote.c: In function 'remoteDispatchDomainGetBlockJobInfo': remote.c:1630: error: 'virDomainBlockJobInfo' undeclared (first use in this function)
Ah. You're running into the same problem that has been previously reported of compiling against the stale installed libvirt.h instead of the just-built in-tree libvirt.h.
Matthias had started a patch for that, but it never got finished.
https://www.redhat.com/archives/libvir-list/2011-May/msg01926.html
I de-installed the port, and then continued with the make process, and it installed just fine.
What is the status of this patch? If this isn't going to make it into the release, I can warn users that this port needs to be de-installed prior to building the port.
It's fixed in git now http://libvirt.org/git/?p=libvirt.git;a=commit;h=b590866bdb0aea20eda5b96883b... But it missed 0.9.4 RC2, so depending on how Daniel plans to do the release of 0.9.4 it might not be included. -- Matthias Bolte http://photron.blogspot.com
On Fri, Jul 29, 2011 at 08:01:48PM +0200, Matthias Bolte wrote:
2011/7/26 Jason Helfman <jhelfman@e-e.com>:
On Tue, Jul 26, 2011 at 12:26:20PM -0600, Eric Blake thus spake:
On 07/26/2011 12:16 PM, Jason Helfman wrote:
remote.c: At top level: remote.c:409: error: negative width in bit-field '_gl_verify_error_if_negative' remote.c: In function 'remoteDispatchDomainGetBlockJobInfo': remote.c:1630: error: 'virDomainBlockJobInfo' undeclared (first use in this function)
Ah. You're running into the same problem that has been previously reported of compiling against the stale installed libvirt.h instead of the just-built in-tree libvirt.h.
Matthias had started a patch for that, but it never got finished.
https://www.redhat.com/archives/libvir-list/2011-May/msg01926.html
I de-installed the port, and then continued with the make process, and it installed just fine.
What is the status of this patch? If this isn't going to make it into the release, I can warn users that this port needs to be de-installed prior to building the port.
It's fixed in git now
http://libvirt.org/git/?p=libvirt.git;a=commit;h=b590866bdb0aea20eda5b96883b...
But it missed 0.9.4 RC2, so depending on how Daniel plans to do the release of 0.9.4 it might not be included.
That will make it, we have still around 3 days before final 0.9.4 :) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 07/26/11 19:45, Eric Blake wrote:
On 07/26/2011 10:40 AM, Jason Helfman wrote:
Thanks! I have this error now, though. No difference between the tarball source and the git sources for this file.
remote.c:1643: error: 'tmp' undeclared (first use in this function) gmake[3]: *** [libvirtd-remote.o] Error 1
That's odd. Line 1643 is in remoteDispatchDomainGetBlockJobInfo, which unconditionally declares virDomainBlockJobInfo tmp at line 1631. I can't see why you would be running into a compilation error here; can you give us better details?
./configure && make ; ~~~ SNIP ~~~ rpc/virnetserver.c: In function 'virNetServerFree': rpc/virnetserver.c:786:5: warning: implicit declaration of function 'virNetServerMDNSFree' [-Wimplicit-function-declaration] rpc/virnetserver.c:786:5: warning: nested extern declaration of 'virNetServerMDNSFree' [-Wnested-externs] rpc/virnetserver.c:786:29: error: 'virNetServer' has no member named 'mdns' ~~~ SNIP ~~~ Slackware64-13.37, but this is not my usual setup. 'config.log' attached. Regards, Z. -- Zdenek Styblik email: stybla@turnovfree.net jabber: stybla@jabber.turnovfree.net
On 07/26/2011 12:28 PM, Zdenek Styblik wrote:
~~~ SNIP ~~~ rpc/virnetserver.c: In function 'virNetServerFree': rpc/virnetserver.c:786:5: warning: implicit declaration of function 'virNetServerMDNSFree' [-Wimplicit-function-declaration] rpc/virnetserver.c:786:5: warning: nested extern declaration of 'virNetServerMDNSFree' [-Wnested-externs] rpc/virnetserver.c:786:29: error: 'virNetServer' has no member named 'mdns'
That's already been solved: https://www.redhat.com/archives/libvir-list/2011-July/msg01836.html -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops ! ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 07/30/2011 03:02 PM, Daniel Veillard wrote:
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops !
ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-)
Daniel
Hi Daniel, I met some memory leaks and invalid read error when I run 'make -C tests valgrind', they may be test cases itself issue, the attachment is a log, please check it. Regards, Alex
2011/8/1 Alex Jia <ajia@redhat.com>:
On 07/30/2011 03:02 PM, Daniel Veillard wrote:
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops !
ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-)
Daniel
Hi Daniel, I met some memory leaks and invalid read error when I run 'make -C tests valgrind', they may be test cases itself issue, the attachment is a log, please check it.
The invalid reads by __strspn_sse42 and __strspn_sse42 are actually bugs in glibc where it uses optimized code on too short strings. Nothing we could fix from the libvirt side. I've send a patch form the memory leak https://www.redhat.com/archives/libvir-list/2011-August/msg00003.html -- Matthias Bolte http://photron.blogspot.com
On 08/01/2011 02:08 AM, Matthias Bolte wrote:
The invalid reads by __strspn_sse42 and __strspn_sse42 are actually bugs in glibc where it uses optimized code on too short strings.
Not so much bugs in glibc (as long as the short reads do not cross page boundaries, and glibc does not use the unitialized data for making any decisions, then it is fair game), as a discrepancy between valgrind exemption rules and the latest glibc. That is, the bug is in valgrind for not exempting that glibc pattern out of the box.
Nothing we could fix from the libvirt side.
Well, libvirt could add an exemption pattern for that particular glibc usage, rather than waiting for valgrind and/or glibc to sync up to one another again. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
At 07/30/2011 03:02 PM, Daniel Veillard Write:
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops !
ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-)
If client(for example: virsh) exits unexpectedly, it will cause libvirtd crashed. Steps to reproduce this problem(vm1 does not run): 1. for ((i=0; i < 50; i++)); do virsh managedsave vm1 & done; killall virsh The reason is that we free virNetServerClient when the refs is not 0. I read the code under the directory src/rpc/, and find we have xxxRef(), but we do not have xxxUnref(). And sometimes we free the data structure if ref is not 0. We add an reference of the data structure, but sometimes we forget to unref it. Thanks Wen Congyang
Daniel
On Mon, Aug 01, 2011 at 04:51:38PM +0800, Wen Congyang wrote:
At 07/30/2011 03:02 PM, Daniel Veillard Write:
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops !
ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-)
If client(for example: virsh) exits unexpectedly, it will cause libvirtd crashed.
Steps to reproduce this problem(vm1 does not run): 1. for ((i=0; i < 50; i++)); do virsh managedsave vm1 & done; killall virsh
The reason is that we free virNetServerClient when the refs is not 0.
I read the code under the directory src/rpc/, and find we have xxxRef(), but we do not have xxxUnref(). And sometimes we free the data structure if ref is not 0. We add an reference of the data structure, but sometimes we forget to unref it.
Okay, so I count 3 issues we should fix before pushing 0.9.4 out - this one (can you open a bugzilla for tracking), are you gonna provide a patch ? Dan Berrange won't be around today - fix crash when mixing sync and async monitor jobs, we are waiting on Eric's finding of his v3 version - domabort seems broken in rc2 https://bugzilla.redhat.com/show_bug.cgi?id=727047 thanks for the heads-up ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
At 08/01/2011 05:04 PM, Daniel Veillard Write:
On Mon, Aug 01, 2011 at 04:51:38PM +0800, Wen Congyang wrote:
At 07/30/2011 03:02 PM, Daniel Veillard Write:
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops !
ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-)
If client(for example: virsh) exits unexpectedly, it will cause libvirtd crashed.
Steps to reproduce this problem(vm1 does not run): 1. for ((i=0; i < 50; i++)); do virsh managedsave vm1 & done; killall virsh
The reason is that we free virNetServerClient when the refs is not 0.
I read the code under the directory src/rpc/, and find we have xxxRef(), but we do not have xxxUnref(). And sometimes we free the data structure if ref is not 0. We add an reference of the data structure, but sometimes we forget to unref it.
Okay, so I count 3 issues we should fix before pushing 0.9.4 out - this one (can you open a bugzilla for tracking), are you gonna provide a patch ? Dan Berrange won't be around today
I open a bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=727071 I am still reading the code under src/rpc. I think I can not fix it before 0.9.4 is released. I hope someone can fix this problem before 0.9.4 is released.
- fix crash when mixing sync and async monitor jobs, we are waiting on Eric's finding of his v3 version - domabort seems broken in rc2 https://bugzilla.redhat.com/show_bug.cgi?id=727047
It's a very simple bug, and I think it's introduced by commit f9a837da. I think the following patch can fix it(not test)
From 42ea23f7f90e551fe74d849be152e8225ee15173 Mon Sep 17 00:00:00 2001 From: Wen Congyang <wency@cn.fujitsu.com> Date: Mon, 1 Aug 2011 17:31:11 +0800 Subject: [PATCH] fix domjobabort's regression
This problem is introduced by commit f9a837da. virDomainObjIsActive() return true means that the vm is running, but we treat it as not running. --- src/qemu/qemu_driver.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index e9aaac1..740934d 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -8074,7 +8074,7 @@ static int qemuDomainAbortJob(virDomainPtr dom) { if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_ABORT) < 0) goto cleanup; - if (virDomainObjIsActive(vm)) { + if (!virDomainObjIsActive(vm)) { qemuReportError(VIR_ERR_OPERATION_INVALID, "%s", _("domain is not running")); goto endjob; -- 1.7.1
thanks for the heads-up !
Daniel
于 2011年08月01日 17:35, Wen Congyang 写道:
At 08/01/2011 05:04 PM, Daniel Veillard Write:
On Mon, Aug 01, 2011 at 04:51:38PM +0800, Wen Congyang wrote:
At 07/30/2011 03:02 PM, Daniel Veillard Write:
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops !
ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-) If client(for example: virsh) exits unexpectedly, it will cause libvirtd crashed.
Steps to reproduce this problem(vm1 does not run): 1. for ((i=0; i< 50; i++)); do virsh managedsave vm1& done; killall virsh
The reason is that we free virNetServerClient when the refs is not 0.
I read the code under the directory src/rpc/, and find we have xxxRef(), but we do not have xxxUnref(). And sometimes we free the data structure if ref is not 0. We add an reference of the data structure, but sometimes we forget to unref it. Okay, so I count 3 issues we should fix before pushing 0.9.4 out - this one (can you open a bugzilla for tracking), are you gonna provide a patch ? Dan Berrange won't be around today I open a bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=727071
I am still reading the code under src/rpc. I think I can not fix it before 0.9.4 is released. I hope someone can fix this problem before 0.9.4 is released.
- fix crash when mixing sync and async monitor jobs, we are waiting on Eric's finding of his v3 version - domabort seems broken in rc2 https://bugzilla.redhat.com/show_bug.cgi?id=727047
It's a very simple bug, and I think it's introduced by commit f9a837da. I think the following patch can fix it(not test)
There was a bug reported https://bugzilla.redhat.com/show_bug.cgi?id=727047 And f362a99a fixed it. Osier
On 08/01/2011 05:04 PM, Daniel Veillard wrote:
On Mon, Aug 01, 2011 at 04:51:38PM +0800, Wen Congyang wrote:
At 07/30/2011 03:02 PM, Daniel Veillard Write:
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops !
ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-) If client(for example: virsh) exits unexpectedly, it will cause libvirtd crashed.
Steps to reproduce this problem(vm1 does not run): 1. for ((i=0; i< 50; i++)); do virsh managedsave vm1& done; killall virsh
The reason is that we free virNetServerClient when the refs is not 0.
I read the code under the directory src/rpc/, and find we have xxxRef(), but we do not have xxxUnref(). And sometimes we free the data structure if ref is not 0. We add an reference of the data structure, but sometimes we forget to unref it. Okay, so I count 3 issues we should fix before pushing 0.9.4 out - this one (can you open a bugzilla for tracking), are you gonna provide a patch ? Dan Berrange won't be around today - fix crash when mixing sync and async monitor jobs, we are waiting on Eric's finding of his v3 version - domabort seems broken in rc2 https://bugzilla.redhat.com/show_bug.cgi?id=727047
thanks for the heads-up !
Daniel
There is another issues needed to be fixed before pushing 0.9.4 The "lock_manager " in qemu.conf still uses old default value . When it is uncommented, it will lead to qemu driver initialization failure: 20:47:45.227: 23830: error : virLockManagerPluginNew:147 : Plugin /usr/lib64/libvirt/lock-driver/fcntl.so not accessible: No such file or directory 20:47:45.227: 23830: error : qemudLoadDriverConfig:457 : Failed to load lock manager fcntl 20:47:45.227: 23830: error : qemudStartup:540 : Missing lock manager implementation ... 20:47:45.227: 23830: error : virStateInitialize:846 : Initialization of QEMU state driver failed I proposed a patch that needs an ACK: https://www.redhat.com/archives/libvir-list/2011-July/msg02097.html
On Mon, Aug 01, 2011 at 08:38:42PM +0800, Guannan Ren wrote:
On 08/01/2011 05:04 PM, Daniel Veillard wrote:
Okay, so I count 3 issues we should fix before pushing 0.9.4 out - this one (can you open a bugzilla for tracking), are you gonna provide a patch ? Dan Berrange won't be around today - fix crash when mixing sync and async monitor jobs, we are waiting on Eric's finding of his v3 version - domabort seems broken in rc2 https://bugzilla.redhat.com/show_bug.cgi?id=727047
thanks for the heads-up !
Daniel
There is another issues needed to be fixed before pushing 0.9.4 The "lock_manager " in qemu.conf still uses old default value . When it is uncommented, it will lead to qemu driver initialization failure:
Yup, I just pushed it, thanks Guannan ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 08/01/2011 05:04 PM, Daniel Veillard wrote:
On Mon, Aug 01, 2011 at 04:51:38PM +0800, Wen Congyang wrote:
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops !
ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-) If client(for example: virsh) exits unexpectedly, it will cause
At 07/30/2011 03:02 PM, Daniel Veillard Write: libvirtd crashed.
Steps to reproduce this problem(vm1 does not run): 1. for ((i=0; i< 50; i++)); do virsh managedsave vm1& done; killall virsh
The reason is that we free virNetServerClient when the refs is not 0.
I read the code under the directory src/rpc/, and find we have xxxRef(), but we do not have xxxUnref(). And sometimes we free the data structure if ref is not 0. We add an reference of the data structure, but sometimes we forget to unref it. Okay, so I count 3 issues we should fix before pushing 0.9.4 out - this one (can you open a bugzilla for tracking), are you gonna provide a patch ? Dan Berrange won't be around today - fix crash when mixing sync and async monitor jobs, we are waiting on Eric's finding of his v3 version - domabort seems broken in rc2 https://bugzilla.redhat.com/show_bug.cgi?id=727047
thanks for the heads-up !
Daniel
There is another issues needed to be fixed before pushing 0.9.4 The "lock_manager " in qemu.conf still uses old default value . When it is uncommented, it will lead to qemu driver initialization failure:
20:47:45.227: 23830: error : virLockManagerPluginNew:147 : Plugin /usr/lib64/libvirt/lock-driver/fcntl.so not accessible: No such file or directory 20:47:45.227: 23830: error : qemudLoadDriverConfig:457 : Failed to load lock manager fcntl 20:47:45.227: 23830: error : qemudStartup:540 : Missing lock manager implementation ... 20:47:45.227: 23830: error : virStateInitialize:846 : Initialization of QEMU state driver failed I have ever discussed this issue with danpb, the above errror is a expected result, because libvirt indeed hasn't implemented 'fcntl' lock at present, in addition, the biggest issue is if we change 'fcntl' to 'sanlock' in qemu.conf then restart
On 08/01/2011 08:38 PM, Guannan Ren wrote: libvirtd service, virsh command will be hung, danpb has fixed this issue in recent, and commit id is 92509413e2da3260b99177de82c85a59cf8ddfd9, so IMHO, this is not a big deal, here is a known bug about this issue. Regards, Alex
I proposed a patch that needs an ACK:
https://www.redhat.com/archives/libvir-list/2011-July/msg02097.html
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 08/01/2011 10:05 PM, ajia wrote:
On 08/01/2011 05:04 PM, Daniel Veillard wrote:
On Mon, Aug 01, 2011 at 04:51:38PM +0800, Wen Congyang wrote:
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops !
ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-) If client(for example: virsh) exits unexpectedly, it will cause
At 07/30/2011 03:02 PM, Daniel Veillard Write: libvirtd crashed.
Steps to reproduce this problem(vm1 does not run): 1. for ((i=0; i< 50; i++)); do virsh managedsave vm1& done; killall virsh
The reason is that we free virNetServerClient when the refs is not 0.
I read the code under the directory src/rpc/, and find we have xxxRef(), but we do not have xxxUnref(). And sometimes we free the data structure if ref is not 0. We add an reference of the data structure, but sometimes we forget to unref it. Okay, so I count 3 issues we should fix before pushing 0.9.4 out - this one (can you open a bugzilla for tracking), are you gonna provide a patch ? Dan Berrange won't be around today - fix crash when mixing sync and async monitor jobs, we are waiting on Eric's finding of his v3 version - domabort seems broken in rc2 https://bugzilla.redhat.com/show_bug.cgi?id=727047
thanks for the heads-up !
Daniel
There is another issues needed to be fixed before pushing 0.9.4 The "lock_manager " in qemu.conf still uses old default value . When it is uncommented, it will lead to qemu driver initialization failure:
20:47:45.227: 23830: error : virLockManagerPluginNew:147 : Plugin /usr/lib64/libvirt/lock-driver/fcntl.so not accessible: No such file or directory 20:47:45.227: 23830: error : qemudLoadDriverConfig:457 : Failed to load lock manager fcntl 20:47:45.227: 23830: error : qemudStartup:540 : Missing lock manager implementation ... 20:47:45.227: 23830: error : virStateInitialize:846 : Initialization of QEMU state driver failed I have ever discussed this issue with danpb, the above errror is a expected result, because libvirt indeed hasn't implemented 'fcntl' lock at present, in addition, the biggest issue is if we change 'fcntl' to 'sanlock' in qemu.conf then restart
On 08/01/2011 08:38 PM, Guannan Ren wrote: libvirtd service, virsh command will be hung, danpb has fixed this issue in recent, and commit id is 92509413e2da3260b99177de82c85a59cf8ddfd9, so IMHO, this is not a big deal, here is a known bug about this issue. https://bugzilla.redhat.com/show_bug.cgi?id=723967
Regards, Alex
I proposed a patch that needs an ACK:
https://www.redhat.com/archives/libvir-list/2011-July/msg02097.html
-- 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
At 08/01/2011 05:04 PM, Daniel Veillard write:
On Mon, Aug 01, 2011 at 04:51:38PM +0800, Wen Congyang wrote:
At 07/30/2011 03:02 PM, Daniel Veillard Write:
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops !
ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-)
If client(for example: virsh) exits unexpectedly, it will cause libvirtd crashed.
Steps to reproduce this problem(vm1 does not run): 1. for ((i=0; i< 50; i++)); do virsh managedsave vm1& done; killall virsh
The reason is that we free virNetServerClient when the refs is not 0.
I read the code under the directory src/rpc/, and find we have xxxRef(), but we do not have xxxUnref(). And sometimes we free the data structure if ref is not 0. We add an reference of the data structure, but sometimes we forget to unref it.
Okay, so I count 3 issues we should fix before pushing 0.9.4 out - this one (can you open a bugzilla for tracking), are you gonna provide a patch ? Dan Berrange won't be around today - fix crash when mixing sync and async monitor jobs, we are waiting on Eric's finding of his v3 version - domabort seems broken in rc2 https://bugzilla.redhat.com/show_bug.cgi?id=727047
I find another problem: Libvirtd can not be restarted after crashed on FC15. The reason is that: we use systemctl to control service on fc15, and the pidfile does not be removed when we stop the service. Thanks Wen Congyang
thanks for the heads-up !
Daniel
On Mon, Aug 01, 2011 at 10:15:11PM +0800, Wen Congyang wrote:
At 08/01/2011 05:04 PM, Daniel Veillard write:
Okay, so I count 3 issues we should fix before pushing 0.9.4 out - this one (can you open a bugzilla for tracking), are you gonna provide a patch ? Dan Berrange won't be around today - fix crash when mixing sync and async monitor jobs, we are waiting on Eric's finding of his v3 version - domabort seems broken in rc2 https://bugzilla.redhat.com/show_bug.cgi?id=727047
I find another problem: Libvirtd can not be restarted after crashed on FC15.
The reason is that: we use systemctl to control service on fc15, and the pidfile does not be removed when we stop the service.
Ah, thanks ! Well it's annoying but not really a release blocker. That said I think I will do the 0.9.4 release tomorrow morning (our time i.e. China) so if someone comes with a patch that would be nice. However it sounds a bit familiar, didn't we had a patch in that area recently ? Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
2011/8/1 Wen Congyang <wency@cn.fujitsu.com>:
At 07/30/2011 03:02 PM, Daniel Veillard Write:
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops !
ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-)
If client(for example: virsh) exits unexpectedly, it will cause libvirtd crashed.
Steps to reproduce this problem(vm1 does not run): 1. for ((i=0; i < 50; i++)); do virsh managedsave vm1 & done; killall virsh
The reason is that we free virNetServerClient when the refs is not 0.
I'm not sure what you mean here. virNetClientFree frees the client when the last ref is removed.
I read the code under the directory src/rpc/, and find we have xxxRef(), but we do not have xxxUnref(). And sometimes we free the data structure if ref is not 0. We add an reference of the data structure, but sometimes we forget to unref it.
We already have an unref function it's called virNetClientFree. Are you referring to virNetClientClose that closes the connection and frees parts of the client? I tried to figure out the cleanup and ref counting logic in the RPC code in order to fix a memory leak triggered by virsh. https://www.redhat.com/archives/libvir-list/2011-July/msg02011.html It's complex and I don't understand it completely, as there is ref counting on multiple levels that is entangled with the event loop. -- Matthias Bolte http://photron.blogspot.com
At 08/01/2011 06:02 PM, Matthias Bolte write:
2011/8/1 Wen Congyang<wency@cn.fujitsu.com>:
At 07/30/2011 03:02 PM, Daniel Veillard Write:
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops !
ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-)
If client(for example: virsh) exits unexpectedly, it will cause libvirtd crashed.
Steps to reproduce this problem(vm1 does not run): 1. for ((i=0; i< 50; i++)); do virsh managedsave vm1& done; killall virsh
The reason is that we free virNetServerClient when the refs is not 0.
I'm not sure what you mean here. virNetClientFree frees the client when the last ref is removed.
I read the code under the directory src/rpc/, and find we have xxxRef(), but we do not have xxxUnref(). And sometimes we free the data structure if ref is not 0. We add an reference of the data structure, but sometimes we forget to unref it.
We already have an unref function it's called virNetClientFree.
Sorry for confusing you. The reason is that: In the function virNetServerClientClose(), we set client->sock to NULL while we still use it. Thanks. Wen Congyang
Are you referring to virNetClientClose that closes the connection and frees parts of the client?
I tried to figure out the cleanup and ref counting logic in the RPC code in order to fix a memory leak triggered by virsh.
https://www.redhat.com/archives/libvir-list/2011-July/msg02011.html
It's complex and I don't understand it completely, as there is ref counting on multiple levels that is entangled with the event loop.
2011/8/1 Wen Congyang <wencongyang@gmail.com>:
At 08/01/2011 06:02 PM, Matthias Bolte write:
2011/8/1 Wen Congyang<wency@cn.fujitsu.com>:
At 07/30/2011 03:02 PM, Daniel Veillard Write:
I actually tagged and pushed the rc2 tarball and rpms yesterday but completely forgot to send the associated mail, oops !
ftp://libvirt.org/libvirt/libvirt-0.9.4-rc2.tar.gz
Hopefully it fixes most of the problems raised with rc1, including a number of leaks. Please report and if you had an issue with rc1 which is still not fixed there (or in git) please raise it ASAP. I'm planning for the final release early Tuesday 2 morning (i.e. late Monday for most :-)
If client(for example: virsh) exits unexpectedly, it will cause libvirtd crashed.
Steps to reproduce this problem(vm1 does not run): 1. for ((i=0; i< 50; i++)); do virsh managedsave vm1& done; killall virsh
The reason is that we free virNetServerClient when the refs is not 0.
I'm not sure what you mean here. virNetClientFree frees the client when the last ref is removed.
I read the code under the directory src/rpc/, and find we have xxxRef(), but we do not have xxxUnref(). And sometimes we free the data structure if ref is not 0. We add an reference of the data structure, but sometimes we forget to unref it.
We already have an unref function it's called virNetClientFree.
Sorry for confusing you.
The reason is that: In the function virNetServerClientClose(), we set client->sock to NULL while we still use it.
Thanks.
Wen Congyang
Ah, you're talking about the server side. I only looked at the client side of the RPC code while trying to understand the memleak. -- Matthias Bolte http://photron.blogspot.com
Steps to reproduce this problem (vm1 is not running): for i in `seq 50`; do virsh managedsave vm1& done; killall virsh Pre-patch, virNetServerClientClose could end up setting client->sock to NULL prior to other cleanup functions trying to use client->sock. This fixes things by checking for NULL in more places, and by deferring the cleanup until after all queued messages have been served. * src/rpc/virnetserverclient.c (virNetServerClientRegisterEvent) (virNetServerClientGetFD, virNetServerClientIsSecure) (virNetServerClientLocalAddrString) (virNetServerClientRemoteAddrString): Check for closed socket. (virNetServerClientClose): Rearrange close sequence. Analysis from Wen Congyang. --- This fixes the problem using the reproduction formula (that is, pre-patch I reproduced the failure; valgrind showed it at: ==29390== Thread 4: ==29390== Invalid read of size 4 ==29390== at 0x3D16608FA0: pthread_mutex_lock (pthread_mutex_lock.c:50) ==29390== by 0x4E9FED2: virMutexLock (threads-pthread.c:85) ==29390== by 0x45DA5E: virNetSocketGetLocalIdentity (virnetsocket.c:741) ==29390== by 0x45554A: virNetServerClientGetLocalIdentity (virnetserverclient.c:401) ==29390== by 0x4420E3: remoteDispatchAuthList (remote.c:1682) ==29390== by 0x4224E4: remoteDispatchAuthListHelper (remote_dispatch.h:19) ==29390== by 0x453EFD: virNetServerProgramDispatchCall (virnetserverprogram.c:375) ==29390== by 0x4539FF: virNetServerProgramDispatch (virnetserverprogram.c:252) ==29390== by 0x456B20: virNetServerHandleJob (virnetserver.c:155) ==29390== by 0x4EA06A3: virThreadPoolWorker (threadpool.c:98) ==29390== by 0x4EA01D6: virThreadHelper (threads-pthread.c:157) ==29390== by 0x3D16606CCA: start_thread (pthread_create.c:301) ==29390== Address 0x10 is not stack'd, malloc'd or (recently) free'd post-patch, libvirtd stays alive and valgrind no longer reports an invalid read). But I'd really like danpb's opinion, if there is time to get that before 0.9.4. /me note to self 'git send-email --cc=...' uses cc as well as honoring .git/config --to to the list; but the list manager sometimes strips cc: lines. Converserly, 'git send-email --to=...' overrides .git/config settings, leaving out the list. I can't win; sorry for the private mails on my previous send attempt. src/rpc/virnetserverclient.c | 29 +++++++++++++++++++---------- 1 files changed, 19 insertions(+), 10 deletions(-) diff --git a/src/rpc/virnetserverclient.c b/src/rpc/virnetserverclient.c index 3c0dba8..2f6c040 100644 --- a/src/rpc/virnetserverclient.c +++ b/src/rpc/virnetserverclient.c @@ -177,7 +177,8 @@ static int virNetServerClientRegisterEvent(virNetServerClientPtr client) client->refs++; VIR_DEBUG("Registering client event callback %d", mode); - if (virNetSocketAddIOCallback(client->sock, + if (!client->sock || + virNetSocketAddIOCallback(client->sock, mode, virNetServerClientDispatchEvent, client, @@ -386,9 +387,10 @@ int virNetServerClientGetTLSKeySize(virNetServerClientPtr client) int virNetServerClientGetFD(virNetServerClientPtr client) { - int fd = 0; + int fd = -1; virNetServerClientLock(client); - fd = virNetSocketGetFD(client->sock); + if (client->sock) + fd = virNetSocketGetFD(client->sock); virNetServerClientUnlock(client); return fd; } @@ -396,9 +398,10 @@ int virNetServerClientGetFD(virNetServerClientPtr client) int virNetServerClientGetLocalIdentity(virNetServerClientPtr client, uid_t *uid, pid_t *pid) { - int ret; + int ret = -1; virNetServerClientLock(client); - ret = virNetSocketGetLocalIdentity(client->sock, uid, pid); + if (client->sock) + ret = virNetSocketGetLocalIdentity(client->sock, uid, pid); virNetServerClientUnlock(client); return ret; } @@ -413,7 +416,7 @@ bool virNetServerClientIsSecure(virNetServerClientPtr client) if (client->sasl) secure = true; #endif - if (virNetSocketIsLocal(client->sock)) + if (client->sock && virNetSocketIsLocal(client->sock)) secure = true; virNetServerClientUnlock(client); return secure; @@ -502,12 +505,16 @@ void virNetServerClientSetDispatcher(virNetServerClientPtr client, const char *virNetServerClientLocalAddrString(virNetServerClientPtr client) { + if (!client->sock) + return NULL; return virNetSocketLocalAddrString(client->sock); } const char *virNetServerClientRemoteAddrString(virNetServerClientPtr client) { + if (!client->sock) + return NULL; return virNetSocketRemoteAddrString(client->sock); } @@ -570,10 +577,7 @@ void virNetServerClientClose(virNetServerClientPtr client) virNetTLSSessionFree(client->tls); client->tls = NULL; } - if (client->sock) { - virNetSocketFree(client->sock); - client->sock = NULL; - } + client->wantClose = true; while (client->rx) { virNetMessagePtr msg @@ -586,6 +590,11 @@ void virNetServerClientClose(virNetServerClientPtr client) virNetMessageFree(msg); } + if (client->sock) { + virNetSocketFree(client->sock); + client->sock = NULL; + } + virNetServerClientUnlock(client); } -- 1.7.4.4
At 08/02/2011 03:53 AM, Eric Blake Write:
Steps to reproduce this problem (vm1 is not running): for i in `seq 50`; do virsh managedsave vm1& done; killall virsh
Pre-patch, virNetServerClientClose could end up setting client->sock to NULL prior to other cleanup functions trying to use client->sock. This fixes things by checking for NULL in more places, and by deferring the cleanup until after all queued messages have been served.
With this patch, libvirtd does not crash.
* src/rpc/virnetserverclient.c (virNetServerClientRegisterEvent) (virNetServerClientGetFD, virNetServerClientIsSecure) (virNetServerClientLocalAddrString) (virNetServerClientRemoteAddrString): Check for closed socket. (virNetServerClientClose): Rearrange close sequence. Analysis from Wen Congyang. ---
This fixes the problem using the reproduction formula (that is, pre-patch I reproduced the failure; valgrind showed it at: ==29390== Thread 4: ==29390== Invalid read of size 4 ==29390== at 0x3D16608FA0: pthread_mutex_lock (pthread_mutex_lock.c:50) ==29390== by 0x4E9FED2: virMutexLock (threads-pthread.c:85) ==29390== by 0x45DA5E: virNetSocketGetLocalIdentity (virnetsocket.c:741) ==29390== by 0x45554A: virNetServerClientGetLocalIdentity (virnetserverclient.c:401) ==29390== by 0x4420E3: remoteDispatchAuthList (remote.c:1682) ==29390== by 0x4224E4: remoteDispatchAuthListHelper (remote_dispatch.h:19) ==29390== by 0x453EFD: virNetServerProgramDispatchCall (virnetserverprogram.c:375) ==29390== by 0x4539FF: virNetServerProgramDispatch (virnetserverprogram.c:252) ==29390== by 0x456B20: virNetServerHandleJob (virnetserver.c:155) ==29390== by 0x4EA06A3: virThreadPoolWorker (threadpool.c:98) ==29390== by 0x4EA01D6: virThreadHelper (threads-pthread.c:157) ==29390== by 0x3D16606CCA: start_thread (pthread_create.c:301) ==29390== Address 0x10 is not stack'd, malloc'd or (recently) free'd
post-patch, libvirtd stays alive and valgrind no longer reports an invalid read). But I'd really like danpb's opinion, if there is time to get that before 0.9.4.
I agree with this patch. But give the chance to danpb to give the final ack before 0.9.4.
/me note to self 'git send-email --cc=...' uses cc as well as honoring .git/config --to to the list; but the list manager sometimes strips cc: lines. Converserly, 'git send-email --to=...' overrides .git/config settings, leaving out the list. I can't win; sorry for the private mails on my previous send attempt.
src/rpc/virnetserverclient.c | 29 +++++++++++++++++++---------- 1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/src/rpc/virnetserverclient.c b/src/rpc/virnetserverclient.c index 3c0dba8..2f6c040 100644 --- a/src/rpc/virnetserverclient.c +++ b/src/rpc/virnetserverclient.c @@ -177,7 +177,8 @@ static int virNetServerClientRegisterEvent(virNetServerClientPtr client)
client->refs++; VIR_DEBUG("Registering client event callback %d", mode); - if (virNetSocketAddIOCallback(client->sock, + if (!client->sock || + virNetSocketAddIOCallback(client->sock, mode, virNetServerClientDispatchEvent, client, @@ -386,9 +387,10 @@ int virNetServerClientGetTLSKeySize(virNetServerClientPtr client)
int virNetServerClientGetFD(virNetServerClientPtr client) { - int fd = 0; + int fd = -1; virNetServerClientLock(client); - fd = virNetSocketGetFD(client->sock); + if (client->sock) + fd = virNetSocketGetFD(client->sock); virNetServerClientUnlock(client); return fd; } @@ -396,9 +398,10 @@ int virNetServerClientGetFD(virNetServerClientPtr client) int virNetServerClientGetLocalIdentity(virNetServerClientPtr client, uid_t *uid, pid_t *pid) { - int ret; + int ret = -1; virNetServerClientLock(client); - ret = virNetSocketGetLocalIdentity(client->sock, uid, pid); + if (client->sock) + ret = virNetSocketGetLocalIdentity(client->sock, uid, pid); virNetServerClientUnlock(client); return ret; } @@ -413,7 +416,7 @@ bool virNetServerClientIsSecure(virNetServerClientPtr client) if (client->sasl) secure = true; #endif - if (virNetSocketIsLocal(client->sock)) + if (client->sock && virNetSocketIsLocal(client->sock)) secure = true; virNetServerClientUnlock(client); return secure; @@ -502,12 +505,16 @@ void virNetServerClientSetDispatcher(virNetServerClientPtr client,
const char *virNetServerClientLocalAddrString(virNetServerClientPtr client) { + if (!client->sock) + return NULL; return virNetSocketLocalAddrString(client->sock); }
const char *virNetServerClientRemoteAddrString(virNetServerClientPtr client) { + if (!client->sock) + return NULL; return virNetSocketRemoteAddrString(client->sock); }
@@ -570,10 +577,7 @@ void virNetServerClientClose(virNetServerClientPtr client) virNetTLSSessionFree(client->tls); client->tls = NULL; } - if (client->sock) { - virNetSocketFree(client->sock); - client->sock = NULL; - } + client->wantClose = true;
while (client->rx) { virNetMessagePtr msg @@ -586,6 +590,11 @@ void virNetServerClientClose(virNetServerClientPtr client) virNetMessageFree(msg); }
+ if (client->sock) { + virNetSocketFree(client->sock); + client->sock = NULL; + } + virNetServerClientUnlock(client); }
On Mon, Aug 01, 2011 at 01:53:19PM -0600, Eric Blake wrote:
Steps to reproduce this problem (vm1 is not running): for i in `seq 50`; do virsh managedsave vm1& done; killall virsh
Pre-patch, virNetServerClientClose could end up setting client->sock to NULL prior to other cleanup functions trying to use client->sock. This fixes things by checking for NULL in more places, and by deferring the cleanup until after all queued messages have been served.
* src/rpc/virnetserverclient.c (virNetServerClientRegisterEvent) (virNetServerClientGetFD, virNetServerClientIsSecure) (virNetServerClientLocalAddrString) (virNetServerClientRemoteAddrString): Check for closed socket. (virNetServerClientClose): Rearrange close sequence. Analysis from Wen Congyang. ---
This fixes the problem using the reproduction formula (that is, pre-patch I reproduced the failure; valgrind showed it at: ==29390== Thread 4: ==29390== Invalid read of size 4 ==29390== at 0x3D16608FA0: pthread_mutex_lock (pthread_mutex_lock.c:50) ==29390== by 0x4E9FED2: virMutexLock (threads-pthread.c:85) ==29390== by 0x45DA5E: virNetSocketGetLocalIdentity (virnetsocket.c:741) ==29390== by 0x45554A: virNetServerClientGetLocalIdentity (virnetserverclient.c:401) ==29390== by 0x4420E3: remoteDispatchAuthList (remote.c:1682) ==29390== by 0x4224E4: remoteDispatchAuthListHelper (remote_dispatch.h:19) ==29390== by 0x453EFD: virNetServerProgramDispatchCall (virnetserverprogram.c:375) ==29390== by 0x4539FF: virNetServerProgramDispatch (virnetserverprogram.c:252) ==29390== by 0x456B20: virNetServerHandleJob (virnetserver.c:155) ==29390== by 0x4EA06A3: virThreadPoolWorker (threadpool.c:98) ==29390== by 0x4EA01D6: virThreadHelper (threads-pthread.c:157) ==29390== by 0x3D16606CCA: start_thread (pthread_create.c:301) ==29390== Address 0x10 is not stack'd, malloc'd or (recently) free'd
post-patch, libvirtd stays alive and valgrind no longer reports an invalid read). But I'd really like danpb's opinion, if there is time to get that before 0.9.4.
/me note to self 'git send-email --cc=...' uses cc as well as honoring .git/config --to to the list; but the list manager sometimes strips cc: lines. Converserly, 'git send-email --to=...' overrides .git/config settings, leaving out the list. I can't win; sorry for the private mails on my previous send attempt.
src/rpc/virnetserverclient.c | 29 +++++++++++++++++++---------- 1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/src/rpc/virnetserverclient.c b/src/rpc/virnetserverclient.c index 3c0dba8..2f6c040 100644 --- a/src/rpc/virnetserverclient.c +++ b/src/rpc/virnetserverclient.c @@ -177,7 +177,8 @@ static int virNetServerClientRegisterEvent(virNetServerClientPtr client)
client->refs++; VIR_DEBUG("Registering client event callback %d", mode); - if (virNetSocketAddIOCallback(client->sock, + if (!client->sock || + virNetSocketAddIOCallback(client->sock, mode, virNetServerClientDispatchEvent, client, @@ -386,9 +387,10 @@ int virNetServerClientGetTLSKeySize(virNetServerClientPtr client)
int virNetServerClientGetFD(virNetServerClientPtr client) { - int fd = 0; + int fd = -1; virNetServerClientLock(client); - fd = virNetSocketGetFD(client->sock); + if (client->sock) + fd = virNetSocketGetFD(client->sock); virNetServerClientUnlock(client); return fd; } @@ -396,9 +398,10 @@ int virNetServerClientGetFD(virNetServerClientPtr client) int virNetServerClientGetLocalIdentity(virNetServerClientPtr client, uid_t *uid, pid_t *pid) { - int ret; + int ret = -1; virNetServerClientLock(client); - ret = virNetSocketGetLocalIdentity(client->sock, uid, pid); + if (client->sock) + ret = virNetSocketGetLocalIdentity(client->sock, uid, pid); virNetServerClientUnlock(client); return ret; } @@ -413,7 +416,7 @@ bool virNetServerClientIsSecure(virNetServerClientPtr client) if (client->sasl) secure = true; #endif - if (virNetSocketIsLocal(client->sock)) + if (client->sock && virNetSocketIsLocal(client->sock)) secure = true; virNetServerClientUnlock(client); return secure; @@ -502,12 +505,16 @@ void virNetServerClientSetDispatcher(virNetServerClientPtr client,
const char *virNetServerClientLocalAddrString(virNetServerClientPtr client) { + if (!client->sock) + return NULL; return virNetSocketLocalAddrString(client->sock); }
const char *virNetServerClientRemoteAddrString(virNetServerClientPtr client) { + if (!client->sock) + return NULL; return virNetSocketRemoteAddrString(client->sock); }
All thes changes look correct & desirable.
@@ -570,10 +577,7 @@ void virNetServerClientClose(virNetServerClientPtr client) virNetTLSSessionFree(client->tls); client->tls = NULL; } - if (client->sock) { - virNetSocketFree(client->sock); - client->sock = NULL; - } + client->wantClose = true;
while (client->rx) { virNetMessagePtr msg @@ -586,6 +590,11 @@ void virNetServerClientClose(virNetServerClientPtr client) virNetMessageFree(msg); }
+ if (client->sock) { + virNetSocketFree(client->sock); + client->sock = NULL; + } + virNetServerClientUnlock(client); }
I'm curious why you have these last 2 hunks of the patc ? The entire of the virNetServerClientClose() is executed under the mutex, so AFAICT moving these 4 lines to later in the function can have no effect. The assignment to wantClose ought to not be needed at this point either, since this flag is used by the server to decide to invoke the virNetServerClientClose method. That all said, these 2 hunks are at worst harmless, so ACK to the patch. 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 :|
On 08/02/2011 04:41 AM, Daniel P. Berrange wrote:
On Mon, Aug 01, 2011 at 01:53:19PM -0600, Eric Blake wrote:
Steps to reproduce this problem (vm1 is not running): for i in `seq 50`; do virsh managedsave vm1& done; killall virsh
Pre-patch, virNetServerClientClose could end up setting client->sock to NULL prior to other cleanup functions trying to use client->sock. This fixes things by checking for NULL in more places, and by deferring the cleanup until after all queued messages have been served.
@@ -570,10 +577,7 @@ void virNetServerClientClose(virNetServerClientPtr client) virNetTLSSessionFree(client->tls); client->tls = NULL; } - if (client->sock) { - virNetSocketFree(client->sock); - client->sock = NULL; - } + client->wantClose = true;
while (client->rx) { virNetMessagePtr msg @@ -586,6 +590,11 @@ void virNetServerClientClose(virNetServerClientPtr client) virNetMessageFree(msg); }
+ if (client->sock) { + virNetSocketFree(client->sock); + client->sock = NULL; + } + virNetServerClientUnlock(client); }
I'm curious why you have these last 2 hunks of the patc ? The entire of the virNetServerClientClose() is executed under the mutex, so AFAICT moving these 4 lines to later in the function can have no effect. The assignment to wantClose ought to not be needed at this point either, since this flag is used by the server to decide to invoke the virNetServerClientClose method.
I did it because virNetMessageFree calls a callback, and I didn't want to audit whether that callback might temporarily drop the mutex or reference client->sock.
That all said, these 2 hunks are at worst harmless, so ACK to the patch.
Fair enough, so I pushed as-is. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
participants (13)
-
ajia -
Alex Jia
-
Daniel P. Berrange -
Daniel Veillard -
Eric Blake -
Guannan Ren -
Jason Helfman -
Matthias Bolte -
Osier Yang -
Ruben Kerkhof -
Wen Congyang -
Wen Congyang -
Zdenek Styblik