[virt-tools-list] Crash in libxml python callback running tests

[Cole Robinson]

On 02/23/2018 08:48 AM, Daniel P. Berrangé wrote:
> I built libvirt using --prefix=/usr/local, and then did *not* run
> 'make install'.
> 
> I then tried to run virt-manager tests
> 
>   ../libvirt/run python3 setup.py test
> 
> It crashed & burned. Initially the problem is that the
> virConnectGetCPUModelNames API call on the test driver fails
> because the cpu_map.xml file isn't installed yet. A libxml
> error is raised because it fails to open this file to parse
> it, here we end up calling back into python and crash and
> burn
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7994882 in PyObject_Call () from /lib64/libpython3.6m.so.1.0
> (gdb) bt
> #0  0x00007ffff7994882 in PyObject_Call () at /lib64/libpython3.6m.so.1.0
> #1  0x00007fffe351cede in libxml_xmlErrorFuncHandler () at /usr/lib64/python3.6/site-packages/libxml2mod.so
> #2  0x00007fffebbe412e in xmlReportError () at /lib64/libxml2.so.2
> #3  0x00007fffebbe599d in __xmlRaiseError () at /lib64/libxml2.so.2
> #4  0x00007fffebc12827 in __xmlLoaderErr () at /lib64/libxml2.so.2
> #5  0x00007fffebbe79c7 in xmlNewInputFromFile () at /lib64/libxml2.so.2
> #6  0x00007fffebc14a57 in xmlDefaultExternalEntityLoader () at /lib64/libxml2.so.2
> #7  0x00007fffebc1488d in xmlLoadExternalEntity () at /lib64/libxml2.so.2
> #8  0x00007fffebc01767 in xmlCtxtReadFile () at /lib64/libxml2.so.2
> #9  0x00007fffed85b194 in virXMLParseHelper (domcode=domcode at entry=31, filename=0x555555b18520 "/usr/local/share/libvirt/cpu_map.xml", xmlStr=xmlStr at entry=0x0, url=url at entry=0x0, ctxt=ctxt at entry=0x7fffffff8d20) at util/virxml.c:813
> #10 0x00007fffed8e41f2 in cpuMapLoad (arch=arch at entry=0x7fffed9fd263 "x86", cb=cb at entry=0x7fffed8dd4a0 <x86MapLoadCallback>, data=0x555555a007d0)
>     at cpu/cpu_map.c:105
> #11 0x00007fffed8e1085 in virCPUx86LoadMap () at cpu/cpu_x86.c:1399
> #12 0x00007fffed8e1085 in virCPUx86DriverOnceInit () at cpu/cpu_x86.c:1413
> #13 0x00007fffed8e11e9 in virCPUx86DriverOnce () at cpu/cpu_x86.c:160
> #14 0x00007ffff7666b37 in __pthread_once_slow () at /lib64/libpthread.so.0
> #15 0x00007fffed8dcce7 in virCPUx86DriverInitialize () at cpu/cpu_x86.c:160
> #16 0x00007fffed8dcda2 in virCPUx86GetMap () at cpu/cpu_x86.c:1425
> #17 0x00007fffed8dcda2 in virCPUx86GetModels (models=0x7fffffff8ec8) at cpu/cpu_x86.c:2820
> #18 0x00007fffed91675c in virConnectGetCPUModelNames (conn=0x555555cb92b0, arch=0x7fffee0aba00 "x86_64", models=0x7fffffff8ec8, flags=0)
>     at libvirt-host.c:1028
> #19 0x00007fffedd131ec in libvirt_virConnectGetCPUModelNames () at /usr/lib64/python3.6/site-packages/libvirtmod.cpython-36m-x86_64-linux-gnu.so
> 
> 
> Valgrind gives similar trace:
> 
> 
> ==18849== Invalid read of size 4
> ==18849==    at 0x4F5A882: PyObject_Call (in /usr/lib64/libpython3.6m.so.1.0)
> ==18849==    by 0x1BD27EDD: ??? (in /usr/lib64/python3.6/site-packages/libxml2mod.so)
> ==18849==    by 0x12FB412D: ??? (in /usr/lib64/libxml2.so.2.9.7)
> ==18849==    by 0x12FB599C: __xmlRaiseError (in /usr/lib64/libxml2.so.2.9.7)
> ==18849==    by 0x12FE2826: __xmlLoaderErr (in /usr/lib64/libxml2.so.2.9.7)
> ==18849==    by 0x12FB79C6: xmlNewInputFromFile (in /usr/lib64/libxml2.so.2.9.7)
> ==18849==    by 0x12FE4A56: ??? (in /usr/lib64/libxml2.so.2.9.7)
> ==18849==    by 0x12FE488C: xmlLoadExternalEntity (in /usr/lib64/libxml2.so.2.9.7)
> ==18849==    by 0x12FD1766: xmlCtxtReadFile (in /usr/lib64/libxml2.so.2.9.7)
> ==18849==    by 0x1136B193: virXMLParseHelper (virxml.c:813)
> ==18849==    by 0x113F41F1: cpuMapLoad (cpu_map.c:105)
> ==18849==    by 0x113F1084: virCPUx86LoadMap (cpu_x86.c:1399)
> ==18849==    by 0x113F1084: virCPUx86DriverOnceInit (cpu_x86.c:1413)
> ==18849==  Address 0x20 is not stack'd, malloc'd or (recently) free'd
> 
> 
> This kind of smells like the same kind of problem that the python lxml
> library has co-existing with otehr stuff that uses libxml, but since
> AFAIK virt-manager isn't using lxml, I'm wondering what's causing this
> crash ?

Thanks for the report, I reproduced. Indeed we aren't using lxml, but
virtinst is setting a libxml2 error callback of its own which appears to
be the culprit, disabling it avoids the crash but results in libxml2
spewing warnings on the console. It's been there for a while so I'm
surprised this hasn't come up before... I'll just drop it

Thanks,
Cole