Bug 1097968
Summary: | libvirt-python API baselineCPU doesn't generate exception | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Jincheng Miao <jmiao> | |
Component: | libvirt | Assignee: | John Ferlan <jferlan> | |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | |
Severity: | medium | Docs Contact: | ||
Priority: | medium | |||
Version: | 7.0 | CC: | dyuan, gsun, honzhang, jmiao, mzhan, rbalakri, xuzhang | |
Target Milestone: | rc | |||
Target Release: | --- | |||
Hardware: | x86_64 | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | libvirt-1.2.7-1.el7 | Doc Type: | Bug Fix | |
Doc Text: |
Cause:
Returned an integer value in function call when a NULL was expected for proper exception reporting
Consequence:
Invalid arguments to libvirt-python con.baselineCPU will cause an unexpected exception return.
Fix:
Return the correct python value (VIR_PY_NONE).
Result:
The libvirt-python con.baselineCPU API will now correctly return the right value resulting in a proper exception frame when invalid arguments are provided.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1097969 (view as bug list) | Environment: | ||
Last Closed: | 2015-03-05 07:35:26 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1097969 |
Description
Jincheng Miao
2014-05-15 01:53:16 UTC
Using upstream - I'm getting the following results - is this what you expect (as it's not really clear to me from your description)? [root@localhost tp-libvirt]# python Python 2.7.5 (default, Feb 19 2014, 13:47:28) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import libvirt >>> con=libvirt.open(None) >>> con.getLibVersion() 1002005 >>> con.baselineCPU([],0) libvirt: error : xmlCPUs in virConnectBaselineCPU must not be NULL Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3191, in baselineCPU if ret is None: raise libvirtError ('virConnectBaselineCPU() failed', conn=self) libvirt.libvirtError: xmlCPUs in virConnectBaselineCPU must not be NULL >>> ret = con.baselineCPU([], 0) libvirt: error : xmlCPUs in virConnectBaselineCPU must not be NULL Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3191, in baselineCPU if ret is None: raise libvirtError ('virConnectBaselineCPU() failed', conn=self) libvirt.libvirtError: xmlCPUs in virConnectBaselineCPU must not be NULL >>> print ret Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'ret' is not defined >>> Perhaps there's another example of a call that has an exception like you expect that will help me figure out exactly what you're looking for. hmmm... I reserved a RHEL7.0 beaker system, installed libvirt... Beaker Test information: HOSTNAME=dell-pem600-01.rhts.eng.bos.redhat.com JOBID=654101 RECIPEID=1357164 RESULT_SERVER=[::1]:7085 DISTRO=RHEL-7.0-20140507.0 ARCHITECTURE=x86_64 # yum install libvirt libvirt-python ... ---> Package libvirt-python.x86_64 0:1.1.1-29.el7 will be installed ... # service libvirtd start Redirecting to /bin/systemctl start libvirtd.service # virsh list --all Id Name State ---------------------------------------------------- # python Python 2.7.5 (default, Feb 11 2014, 07:46:25) [GCC 4.8.2 20140120 (Red Hat 4.8.2-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import libvirt >>> con=libvirt.open(None) >>> con.getLibVersion() 1001001 >>> con.baselineCPU([],0) libvirt: error : xmlCPUs in virConnectBaselineCPU must not be NULL -1 >>> ret = con.baselineCPU([],0) libvirt: error : xmlCPUs in virConnectBaselineCPU must not be NULL >>> # But if I look at the git history for the 7.0 package - it's supposed to have the commit for bz 912170 which I believe is the fix for this issue. Additionally, if I look at the code in "/usr/lib64/python2.7/site-packages/libvirt.py" I see: def baselineCPU(self, xmlCPUs, flags=0): """Computes the most feature-rich CPU which is compatible with all given host CPUs. """ ret = libvirtmod.virConnectBaselineCPU(self._o, xmlCPUs, flags) if ret is None: raise libvirtError ('virConnectBaselineCPU() failed', conn=self) return ret ... Frustrating... but I think I found the commit I need now in the (now) split libvirt-python code - 8dd64f07ea2c4c53b51a5170f0a3db0c53a094da: Author: Don Dugger <donald.d.dugger> Date: Tue Nov 26 16:53:20 2013 +0000 Return right error code for baselineCPU This Python interface code is returning a -1 on errors for the `baselineCPU' API. Since this API is supposed to return a pointer the error return value should really be VIR_PY_NONE. Signed-off-by: Don Dugger <donald.d.dugger> diff --git a/libvirt-override.c b/libvirt-override.c index 3ef81dd..4cc64b7 100644 --- a/libvirt-override.c +++ b/libvirt-override.c @@ -4496,13 +4496,13 @@ libvirt_virConnectBaselineCPU(PyObject *self ATTRIBUTE_U ncpus = PyList_Size(list); if (VIR_ALLOC_N(xmlcpus, ncpus) < 0) - return VIR_PY_INT_FAIL; + return VIR_PY_NONE; for (i = 0; i < ncpus; i++) { xmlcpus[i] = PyString_AsString(PyList_GetItem(list, i)); if (xmlcpus[i] == NULL) { VIR_FREE(xmlcpus); - return VIR_PY_INT_FAIL; + return VIR_PY_NONE; } } } @@ -4514,13 +4514,13 @@ libvirt_virConnectBaselineCPU(PyObject *self ATTRIBUTE_U VIR_FREE(xmlcpus); if (base_cpu == NULL) - return VIR_PY_INT_FAIL; + return VIR_PY_NONE; pybase_cpu = PyString_FromString(base_cpu); VIR_FREE(base_cpu); if (pybase_cpu == NULL) - return VIR_PY_INT_FAIL; + return VIR_PY_NONE; return pybase_cpu; } Since this is upstream and thus will be in 7.1, I assume you are not looking for a backport to 7.0, correct? If not, then I'll figure what state to change this to... If you are looking for a 7.0 backport, that'll probably mean this needs to be cloned to a 7.0.z stream (although I'm not quite sure of the process). (In reply to John Ferlan from comment #3) > Since this is upstream and thus will be in 7.1, I assume you are not looking > for a backport to 7.0, correct? If not, then I'll figure what state to > change this to... If you are looking for a 7.0 backport, that'll probably > mean this needs to be cloned to a 7.0.z stream (although I'm not quite sure > of the process). Yes, I had set a flag to rhel-7.1.0, and there is no customer needs it be backport-ed to 7.0. Thanks, Jincheng Miao Moving to POST since code is already upstream Verify it as follows. The result is expected. Move its status to VERIFIED. [root@localhost ~]# rpm -q libvirt libvirt-python libvirt-1.2.8-8.el7.x86_64 libvirt-python-1.2.8-5.el7.x86_64 [root@localhost ~]# python Python 2.7.5 (default, Feb 11 2014, 07:46:25) [GCC 4.8.2 20140120 (Red Hat 4.8.2-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import libvirt >>> con=libvirt.open(None) >>> con.baselineCPU([], 0) libvirt: error : xmlCPUs in virConnectBaselineCPU must not be NULL Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3326, in baselineCPU if ret is None: raise libvirtError ('virConnectBaselineCPU() failed', conn=self) libvirt.libvirtError: xmlCPUs in virConnectBaselineCPU must not be NULL >>> ret = con.baselineCPU([], 0) libvirt: error : xmlCPUs in virConnectBaselineCPU must not be NULL Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3326, in baselineCPU if ret is None: raise libvirtError ('virConnectBaselineCPU() failed', conn=self) libvirt.libvirtError: xmlCPUs in virConnectBaselineCPU must not be NULL >>> Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0323.html |