- Devel - libvirt List Archives

Re: [libvirt] Cannot enumerate physical devices with libvirt 0.7.6
by Frédéric Grelot 17 Feb '10

17 Feb '10

Hi Dave and all > have four on my test system, which I just installed. How did you > install the box, install F12, then what? Just to rule this out, did > you rebuild the RPM? I first built it from source (0.7.6), but, when the package was released in rawvirt (repo enabled in my system), I uninstalled my version ("make uninstall" in the directory where I installed it from), then installed that of rawvirt... When I started having these problems, I uninstalled / reinstalled again, but it didn't change anything. Well... you solved my problem anyway : to sort this out, I tried that again. Thus I noticed that after having uninstalled everything (yum remove + make uninstall), the "libvirtd" command still "worked" (with errors). I checked... and there was a /sbin/libvirtd, left by I-don-t-know-which install! . It was one of those last, undoubtly, since "libvirtd --version" actually returned 0.7.6... (And, of course, in the default PATH, /sbin stands before /usr/bin/...) I removed (=backuped just in case...) it, installed with yum, and it works at last! Thanks for your help, you got me to the right path... And sorry for the inconvenient of a "custom" install... However, I don't explain why this libvirtd was left there... Were the paths changed lately? Frederic ----- "Dave Allan" <dallan(a)redhat.com> a écrit : > On 02/16/2010 03:04 PM, Frédéric Grelot wrote: > > Yep, here is what I get (see at the end) : > > (snip) > > > > I think the times when I get those lines matches with my "virsh > nodedev-list" requests (or something like this : virt-manager tries to > create a vm, add hardware...). > > > > Does this help? > > That's odd, you only have two entries in the node driver array, and I > > have four on my test system, which I just installed. How did you > install the box, install F12, then what? Just to rule this out, did > you > rebuild the RPM? > > > Frederic. > > > > > > ----- "Dave Allan"<dallan(a)redhat.com> a écrit : > > > >> On 02/16/2010 03:00 AM, Frédéric Grelot wrote: > >>>> Daniel was referring to the libvirt udev driver--the libvirt > code > >> that > >>>> > >>>> interacts with udev--not to udev itself, which is what you're > >> testing > >>>> > >>>> with udevadm. > >>> > >>> Ok, sorry... At least I ensured that udev itself is on... > >>> > >>>> In any of your logs when you have libvirt debug logging > >>>> turned on, do you see the message: > >>>> > >>>> Registering udev node device backend > >>> > >>> Nope, I checked in /var/log/* and libvirt.log in debug mode > (which, > >> after 1 1/2 day of "debug" activity enabled, is already 2Gb!) > >>> There is no mention of udev. I think it means that the udev > driver > >> is not loaded in libvirt? How could enable it then? (or produce > some > >> message telling me why it is not) ? > >>> > >>> > >>>> These messages are the result of not being able to find the > >> device, > >>>> which is consistent with the other things you're seeing. These > >> are > >>>> all symptoms of the node device code not running. > >>> > >>> OK, I'll wait for your suggestions... > >> > >> Do you see messages like: > >> > >> > >> 14:35:01.849: debug : do_open:1205 : node driver 0 Test returned > >> DECLINED > >> 14:35:01.849: debug : do_open:1205 : node driver 1 ESX returned > >> DECLINED > >> 14:35:01.849: debug : do_open:1205 : node driver 2 remote returned > >> DECLINED > >> 14:35:01.849: debug : do_open:1205 : node driver 3 > udevDeviceMonitor > >> returned SUCCESS > >> > >> in your debug log? > >> > >> > >>> Frederic. > >>> > >>> > >>>> > >>>>> Have you any other Idea? > >>>>> Frederic. > >>>>> > >>>>> > >>>>> ----- "Daniel P. Berrange"<berrange(a)redhat.com> a écrit : > >>>>> > >>>>>> On Fri, Feb 12, 2010 at 08:05:21PM +0100, Fr?d?ric Grelot > wrote: > >>>>>>> Hi all, > >>>>>>> > >>>>>>> I often update my F12 box with the rawvirt repository, which > >>>>>>> just > >>>>>> installed libvirt 0.7.6. Since that, I cannot enumerate > physical > >>>>>> devices (and thus get a beautiful error when I start one of my > >> vms > >>>>>> that should use a USB device). > >>>>>>> > >>>>>>> I don't think I changed anything else on that box, and, of > >>>>>>> course, I > >>>>>> already restarted the libvirt daemon. > >>>>>>> I haven't restarted the server itself, because it is > currently > >>>>>>> used, > >>>>>> but I could do it if necessary... > >>>>>>> > >>>>>>> I make good use of the qemu hypervisor, and I'm looking > forward > >>>>>>> to > >>>>>> solve this issue! > >>>>>>> > >>>>>>> Frederic. > >>>>>>> > >>>>>>> # libvirtd --version libvirtd (libvirt) 0.7.6 > >>>>>>> > >>>>>>> # virsh --version 0.7.6 > >>>>>>> > >>>>>>> # virsh nodedev-list error :Failed to count node devices > error > >>>>>>> :this function is not supported by the hypervisor: > >>>>>> virNodeNumOfDevices > >>>>>> > >>>>>> It would appear that the udev driver failed to start - there > are > >>>>>> probably messages in syslog about the problem > >>>>>> > >>>>>> > >>>>>> Regards, Daniel -- |: Red Hat, Engineering, London -o- > >>>>>> http://people.redhat.com/berrange/ :| |: http://libvirt.org > -o- > >>>>>> http://virt-manager.org -o- http://ovirt.org :| |: > >>>>>> http://autobuild.org -o- > http://search.cpan.org/~danberr/ > >> :| > >>>>>> |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF > F742 > >>>>>> 7D3B 9505 :| > >>>>> > >>>>> -- libvir-list mailing list libvir-list(a)redhat.com > >>>>> https://www.redhat.com/mailman/listinfo/libvir-list > >>> > >>> -- > >>> libvir-list mailing list > >>> libvir-list(a)redhat.com > >>> https://www.redhat.com/mailman/listinfo/libvir-list > > > > -- > > libvir-list mailing list > > libvir-list(a)redhat.com > > https://www.redhat.com/mailman/listinfo/libvir-list

2 1

[libvirt] Repost [PATCH] Fix whitespace in domain.rng
by Matthew Booth 17 Feb '10

17 Feb '10

Rebased so it applies.

1 1

[libvirt] [PATCH] Fix whitespace in domain.rng
by Matthew Booth 17 Feb '10

17 Feb '10

* src/schemas/domain.rng: Replace tabs with 8 spaces --- docs/schemas/domain.rng | 52 +++++++++++++++++++++++----------------------- 1 files changed, 26 insertions(+), 26 deletions(-) diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng index a834705..1ac5943 100644 --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -538,7 +538,7 @@ <ref name="unsignedInt"/> </attribute> <optional> - <ref name="address"/> + <ref name="address"/> </optional> </element> </define> @@ -603,7 +603,7 @@ </group> </choice> <optional> - <ref name="address"/> + <ref name="address"/> </optional> </element> </define> @@ -762,7 +762,7 @@ </element> </optional> <optional> - <ref name="address"/> + <ref name="address"/> </optional> </interleave> </define> @@ -1015,7 +1015,7 @@ </element> </optional> <optional> - <ref name="address"/> + <ref name="address"/> </optional> </interleave> </define> @@ -1159,9 +1159,9 @@ <ref name="guestfwdTarget"/> <ref name="virtioTarget"/> </choice> - <optional> - <ref name="address"/> - </optional> + <optional> + <ref name="address"/> + </optional> </interleave> </element> </define> @@ -1183,7 +1183,7 @@ </attribute> </optional> <optional> - <ref name="address"/> + <ref name="address"/> </optional> </element> </define> @@ -1212,12 +1212,12 @@ <group> <element name="source"> <choice> - <group> + <group> <ref name="usbproduct"/> - <optional> - <ref name="usbaddress"/> - </optional> - </group> + <optional> + <ref name="usbaddress"/> + </optional> + </group> <ref name="usbaddress"/> <element name="address"> <ref name="pciaddress"/> @@ -1276,7 +1276,7 @@ </optional> <optional> <attribute name="bus"> - <ref name="driveBus"/> + <ref name="driveBus"/> </attribute> </optional> <attribute name="unit"> @@ -1415,18 +1415,18 @@ <define name="address"> <element name="address"> <choice> - <group> - <attribute name="type"> - <value>pci</value> - </attribute> - <ref name="pciaddress"/> - </group> - <group> - <attribute name="type"> - <value>drive</value> - </attribute> - <ref name="driveaddress"/> - </group> + <group> + <attribute name="type"> + <value>pci</value> + </attribute> + <ref name="pciaddress"/> + </group> + <group> + <attribute name="type"> + <value>drive</value> + </attribute> + <ref name="driveaddress"/> + </group> </choice> </element> </define> -- 1.6.6

2 1

[libvirt] [PATCH] build: inform libtool of m4 directory
by Eric Blake 17 Feb '10

17 Feb '10

Silence a libtoolize warning. * configure.ac (AC_CONFIG_MACRO_DIR): Add. --- Libtool spits out this warning during ./autogen.sh: | libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and | libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. I've checked that there is no significant difference in the generated files when applying this patch to silence the warning, and that autoconf 2.59 supplied this macro. configure.ac | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 1c7c24c..743a357 100644 --- a/configure.ac +++ b/configure.ac @@ -4,6 +4,7 @@ AC_INIT([libvirt], [0.7.6]) AC_CONFIG_SRCDIR([src/libvirt.c]) AC_CONFIG_AUX_DIR([build-aux]) AC_CONFIG_HEADERS([config.h]) +AC_CONFIG_MACRO_DIR([m4]) dnl Make automake keep quiet about wildcards & other GNUmake-isms AM_INIT_AUTOMAKE([-Wno-portability]) -- 1.6.6

2 1

[libvirt] [PATCH] Fix macvtap device tear down problem on virsh destroy
by Stefan Berger 17 Feb '10

17 Feb '10

This patch fixes the problem with the tear down of the macvtap device when issuing a 'virsh destroy' by moving the tear down block past the point of killing the Qemu process. It seems necessary to loop at least once in the case of 'virsh destory' since the device seems to be busy for a while after the Qemu process has been killed. This also still properly tears down the macvtap device when the VM is 'virsh shutdown'ed or halted from inside. Signed-off-by: Stefan Berger <stefanb(a)us.ibm.com>

2 5

[libvirt] [PATCH v2 0/9] New public API for computing baseline CPU
by Jiri Denemark 17 Feb '10

17 Feb '10

Version 2 changes: - rebased (mainly for conn argument removal) - swapped array and number of elements in array parameters - fixed absolute paths in generated RPC code - added python bindings for virConnectBaselineCPU - fixed uninitialized variable in cpuDecode, which wasn't revealed by gcc :-( This series introduces a new virConnectBaselineCPU() API call for computing baseline CPU model from a set of host CPU definitions. The call accepts a list of <cpu>...</cpu> xml definitions taken from host capabilities and returns an xml description of a guest CPU which is supported by all hosts. virsh is little bit less picky and accepts a file containing host CPU definitions. It doesn't care what is outside of the <cpu/> tag, which allows for concatenating outputs of virsh capabilities from several hosts and feeding the result to virsh cpu-baseline. This series can also be found on cpu-baseline branch of git://gitorious.org/~jirka/libvirt/jirka-staging.git In practice it works like this: # virsh cpu-baseline /dev/stdin >guest-cpu <<EOF <capabilities> <host> <cpu> <arch>x86_64</arch> <model>core2duo</model> <topology sockets='1' cores='2' threads='1'/> <feature name='lahf_lm'/> <feature name='xtpr'/> <feature name='cx16'/> <feature name='tm2'/> <feature name='est'/> <feature name='vmx'/> </cpu> </host> </capabilities> <cpu> <arch>i686</arch> <model>pentiumpro</model> <topology sockets='1' cores='2' threads='1'/> <feature name='vme'/> <feature name='pse36'/> <feature name='pni'/> <feature name='monitor'/> <feature name='ssse3'/> </cpu> <cpu> <arch>x86_64</arch> <model>phenom</model> </cpu> EOF # cat guest-cpu <cpu match='exact'> <model>qemu32</model> <feature policy='require' name='monitor'/> <feature policy='require' name='pse36'/> </cpu> Jiri Denemark (9): Functions for computing baseline CPU from a set of host CPUs Implement cpuArchBaseline in generic CPU driver Implement cpuArchBaseline in x86 CPU driver virConnectBaselineCPU public API Internal driver API for virConnectBaselineCPU virConnectBaselineCPU public API implementation Wire protocol format and dispatcher for virConnectBaselineCPU Implement cpuBaseline in remote and qemu drivers cpu-baseline command for virsh daemon/remote.c | 25 +++++++ daemon/remote_dispatch_args.h | 1 + daemon/remote_dispatch_prototypes.h | 8 ++ daemon/remote_dispatch_ret.h | 1 + daemon/remote_dispatch_table.h | 5 ++ include/libvirt/libvirt.h.in | 18 +++++ python/generator.py | 1 + python/libvirt-override-api.xml | 7 ++ python/libvirt-override.c | 52 +++++++++++++++ src/cpu/cpu.c | 123 ++++++++++++++++++++++++++++++++++- src/cpu/cpu.h | 21 ++++++- src/cpu/cpu_generic.c | 104 +++++++++++++++++++++++++++++- src/cpu/cpu_x86.c | 88 ++++++++++++++++++++++++- src/driver.h | 6 ++ src/esx/esx_driver.c | 1 + src/libvirt.c | 57 ++++++++++++++++ src/libvirt_private.syms | 2 + src/libvirt_public.syms | 1 + src/lxc/lxc_driver.c | 1 + src/opennebula/one_driver.c | 1 + src/openvz/openvz_driver.c | 1 + src/phyp/phyp_driver.c | 1 + src/qemu/qemu_driver.c | 14 ++++ src/remote/remote_driver.c | 32 +++++++++ src/remote/remote_protocol.c | 22 ++++++ src/remote/remote_protocol.h | 20 ++++++ src/remote/remote_protocol.x | 18 +++++- src/test/test_driver.c | 1 + src/uml/uml_driver.c | 1 + src/vbox/vbox_tmpl.c | 1 + src/xen/xen_driver.c | 1 + tools/virsh.c | 72 ++++++++++++++++++++ tools/virsh.pod | 8 ++ 33 files changed, 709 insertions(+), 6 deletions(-)

4 32

[libvirt] [PATCH] vbox_tmpl.c: avoid leak on OOM error path
by Jim Meyering 17 Feb '10

17 Feb '10

We have to free def here, rather than after "cleanup:", because "cleanup:" is on the successful-return path. >From 2c7800c3560f03fd77e4a458cb0e557165faed3f Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Mon, 15 Feb 2010 17:54:15 +0100 Subject: [PATCH] vbox_tmpl.c: avoid leak on OOM error path * src/vbox/vbox_tmpl.c (vboxDomainDumpXML): Free def upon virAsprintf failure. --- src/vbox/vbox_tmpl.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/vbox/vbox_tmpl.c b/src/vbox/vbox_tmpl.c index 68dffd2..1fb8d56 100644 --- a/src/vbox/vbox_tmpl.c +++ b/src/vbox/vbox_tmpl.c @@ -6059,14 +6059,15 @@ static char *vboxNetworkDumpXML(virNetworkPtr network, int flags ATTRIBUTE_UNUSE if (VIR_ALLOC(def) < 0) { virReportOOMError(); goto cleanup; } if (virAsprintf(&networkNameUtf8, "HostInterfaceNetworking-%s", network->name) < 0) { virReportOOMError(); + VIR_FREE(def); goto cleanup; } PRUnichar *networkInterfaceNameUtf16 = NULL; IHostNetworkInterface *networkInterface = NULL; VBOX_UTF8_TO_UTF16(network->name, &networkInterfaceNameUtf16); -- 1.7.0.181.g41533

2 6

Re: [libvirt] Cannot enumerate physical devices with libvirt 0.7.6
by Frédéric Grelot 16 Feb '10

16 Feb '10

Yep, here is what I get (see at the end) : 14:06:22.071: debug : do_open:1110 : name "qemu:///system" to URI components: scheme qemu opaque (null) authority (null) server (null) user (null) port 0 path /system 14:06:22.071: debug : do_open:1120 : trying driver 0 (Test) ... 14:06:22.071: debug : do_open:1126 : driver 0 Test returned DECLINED 14:06:22.071: debug : do_open:1120 : trying driver 1 (OPENVZ) ... 14:06:22.071: debug : do_open:1126 : driver 1 OPENVZ returned DECLINED 14:06:22.071: debug : do_open:1120 : trying driver 2 (VBOX) ... 14:06:22.071: debug : do_open:1126 : driver 2 VBOX returned DECLINED 14:06:22.071: debug : do_open:1120 : trying driver 3 (remote) ... 14:06:22.071: debug : do_open:1126 : driver 3 remote returned DECLINED 14:06:22.071: debug : do_open:1120 : trying driver 4 (QEMU) ... 14:06:22.071: debug : do_open:1126 : driver 4 QEMU returned SUCCESS 14:06:22.071: debug : do_open:1146 : network driver 0 Test returned DECLINED 14:06:22.071: debug : do_open:1146 : network driver 1 VBOX returned DECLINED 14:06:22.071: debug : do_open:1146 : network driver 2 remote returned DECLINED 14:06:22.071: debug : do_open:1146 : network driver 3 Network returned SUCCESS 14:06:22.071: debug : do_open:1165 : interface driver 0 Test returned DECLINED 14:06:22.071: debug : do_open:1165 : interface driver 1 remote returned DECLINED 14:06:22.072: debug : do_open:1185 : storage driver 0 Test returned DECLINED 14:06:22.072: debug : do_open:1185 : storage driver 1 VBOX returned DECLINED 14:06:22.072: debug : do_open:1185 : storage driver 2 remote returned DECLINED 14:06:22.072: debug : do_open:1185 : storage driver 3 storage returned SUCCESS 14:06:22.072: debug : do_open:1205 : node driver 0 Test returned DECLINED 14:06:22.072: debug : do_open:1205 : node driver 1 remote returned DECLINED 14:06:22.072: debug : do_open:1232 : secret driver 0 Test returned DECLINED 14:06:22.072: debug : do_open:1232 : secret driver 1 remote returned DECLINED 14:06:22.072: debug : do_open:1232 : secret driver 2 secret returned SUCCESS 14:06:22.072: debug : virConnectClose:1381 : conn=0x1eaf0b0 I think the times when I get those lines matches with my "virsh nodedev-list" requests (or something like this : virt-manager tries to create a vm, add hardware...). Does this help? Frederic. ----- "Dave Allan" <dallan(a)redhat.com> a écrit : > On 02/16/2010 03:00 AM, Frédéric Grelot wrote: > >> Daniel was referring to the libvirt udev driver--the libvirt code > that > >> > >> interacts with udev--not to udev itself, which is what you're > testing > >> > >> with udevadm. > > > > Ok, sorry... At least I ensured that udev itself is on... > > > >> In any of your logs when you have libvirt debug logging > >> turned on, do you see the message: > >> > >> Registering udev node device backend > > > > Nope, I checked in /var/log/* and libvirt.log in debug mode (which, > after 1 1/2 day of "debug" activity enabled, is already 2Gb!) > > There is no mention of udev. I think it means that the udev driver > is not loaded in libvirt? How could enable it then? (or produce some > message telling me why it is not) ? > > > > > >> These messages are the result of not being able to find the > device, > >> which is consistent with the other things you're seeing. These > are > >> all symptoms of the node device code not running. > > > > OK, I'll wait for your suggestions... > > Do you see messages like: > > > 14:35:01.849: debug : do_open:1205 : node driver 0 Test returned > DECLINED > 14:35:01.849: debug : do_open:1205 : node driver 1 ESX returned > DECLINED > 14:35:01.849: debug : do_open:1205 : node driver 2 remote returned > DECLINED > 14:35:01.849: debug : do_open:1205 : node driver 3 udevDeviceMonitor > returned SUCCESS > > in your debug log? > > > > Frederic. > > > > > >> > >>> Have you any other Idea? > >>> Frederic. > >>> > >>> > >>> ----- "Daniel P. Berrange"<berrange(a)redhat.com> a écrit : > >>> > >>>> On Fri, Feb 12, 2010 at 08:05:21PM +0100, Fr?d?ric Grelot wrote: > >>>>> Hi all, > >>>>> > >>>>> I often update my F12 box with the rawvirt repository, which > >>>>> just > >>>> installed libvirt 0.7.6. Since that, I cannot enumerate physical > >>>> devices (and thus get a beautiful error when I start one of my > vms > >>>> that should use a USB device). > >>>>> > >>>>> I don't think I changed anything else on that box, and, of > >>>>> course, I > >>>> already restarted the libvirt daemon. > >>>>> I haven't restarted the server itself, because it is currently > >>>>> used, > >>>> but I could do it if necessary... > >>>>> > >>>>> I make good use of the qemu hypervisor, and I'm looking forward > >>>>> to > >>>> solve this issue! > >>>>> > >>>>> Frederic. > >>>>> > >>>>> # libvirtd --version libvirtd (libvirt) 0.7.6 > >>>>> > >>>>> # virsh --version 0.7.6 > >>>>> > >>>>> # virsh nodedev-list error :Failed to count node devices error > >>>>> :this function is not supported by the hypervisor: > >>>> virNodeNumOfDevices > >>>> > >>>> It would appear that the udev driver failed to start - there are > >>>> probably messages in syslog about the problem > >>>> > >>>> > >>>> Regards, Daniel -- |: Red Hat, Engineering, London -o- > >>>> http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- > >>>> http://virt-manager.org -o- http://ovirt.org :| |: > >>>> http://autobuild.org -o- http://search.cpan.org/~danberr/ > :| > >>>> |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 > >>>> 7D3B 9505 :| > >>> > >>> -- libvir-list mailing list libvir-list(a)redhat.com > >>> https://www.redhat.com/mailman/listinfo/libvir-list > > > > -- > > libvir-list mailing list > > libvir-list(a)redhat.com > > https://www.redhat.com/mailman/listinfo/libvir-list

2 1

Re: [libvirt] Cannot enumerate physical devices with libvirt 0.7.6
by Frédéric Grelot 16 Feb '10

16 Feb '10

The udev driver is actually fully loaded, I even entered "udevadm monitor" in a console, and it reacted as expected when I plugged/unplugged an usb mouse... There is nothing about it in dmesg/boot/message.log, nor libvirt.log (I set up libvirt daemon to log at debug level in /var/log/libvirt/libvirt.log). By the way, I noticed that libvirt generates tons of "error : qemuMonitorTextGetBlockStatsInfo:698 : invalid argument in no stats found for device virtio-diskX" while virt-manager is running (it stops as soon as I stop virt-manager). Is it linked with the bug I saw on the list about libvirt taking over memory after time isn't it? Have you any other Idea? Frederic. ----- "Daniel P. Berrange" <berrange(a)redhat.com> a écrit : > On Fri, Feb 12, 2010 at 08:05:21PM +0100, Fr?d?ric Grelot wrote: > > Hi all, > > > > I often update my F12 box with the rawvirt repository, which just > installed libvirt 0.7.6. Since that, I cannot enumerate physical > devices (and thus get a beautiful error when I start one of my vms > that should use a USB device). > > > > I don't think I changed anything else on that box, and, of course, I > already restarted the libvirt daemon. > > I haven't restarted the server itself, because it is currently used, > but I could do it if necessary... > > > > I make good use of the qemu hypervisor, and I'm looking forward to > solve this issue! > > > > Frederic. > > > > # libvirtd --version > > libvirtd (libvirt) 0.7.6 > > > > # virsh --version > > 0.7.6 > > > > # virsh nodedev-list > > error :Failed to count node devices > > error :this function is not supported by the hypervisor: > virNodeNumOfDevices > > It would appear that the udev driver failed to start - there are > probably > messages in syslog about the problem > > > Regards, > Daniel > -- > |: Red Hat, Engineering, London -o- > http://people.redhat.com/berrange/ :| > |: http://libvirt.org -o- http://virt-manager.org -o- > http://ovirt.org :| > |: http://autobuild.org -o- > http://search.cpan.org/~danberr/ :| > |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B > 9505 :|

2 3

[libvirt] [PATCH] vshCommandParse: placate coverity
by Jim Meyering 16 Feb '10

16 Feb '10

Here are two patches to avoid semblance of a leak. One adds a useless use of VIR_FREE. The other adds an assertion that the pointer to would-be-leaked storage is NULL. There's already an assertion in this file, so no need to add an "#include ...". Take your pick. >From 2070262e7f1a4803e06a6f75bd96091c5754164d Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Tue, 16 Feb 2010 14:34:48 +0100 Subject: [PATCH] vshCommandParse: placate coverity There is no real leak here, but Coverity-Prevent thinks there is. It does not see that while there are four ways to return from vshCommandGetToken with VSH_TK_END, none of them results in allocation of a result. * tools/virsh.c (vshCommandParse): Add a (currently) useless VIR_FREE, to ensure that we never leak when vshCommandGetToken returns VSH_TK_END. --- tools/virsh.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index 7db48d9..4ffa154 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -8222,8 +8222,10 @@ vshCommandParse(vshControl *ctl, char *cmdstr) str = end; - if (tk == VSH_TK_END) + if (tk == VSH_TK_END) { + VIR_FREE(tkdata); break; + } if (tk == VSH_TK_ERROR) goto syntaxError; -- 1.7.0.181.g41533 >From 98b0c148d7fd7e11eed7786189db60b485612b51 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Tue, 16 Feb 2010 14:34:48 +0100 Subject: [PATCH] vshCommandParse: placate coverity * tools/virsh.c (vshCommandParse): Inform static analyzers that there is no risk of leak when vshCommandGetToken returns VSH_TK_END. --- tools/virsh.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index 7db48d9..5c45d1c 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -8222,8 +8222,10 @@ vshCommandParse(vshControl *ctl, char *cmdstr) str = end; - if (tk == VSH_TK_END) + if (tk == VSH_TK_END) { + assert (tkdata == NULL); break; + } if (tk == VSH_TK_ERROR) goto syntaxError; -- 1.7.0.181.g41533

2 2