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@entry=31, > filename=0x555555b18520 "/usr/local/share/libvirt/cpu_map.xml", > xmlStr=xmlStr@entry=0x0, url=url@entry=0x0, ctxt=ctxt@entry=0x7fffffff8d20) > at util/virxml.c:813 > #10 0x00007fffed8e41f2 in cpuMapLoad (arch=arch@entry=0x7fffed9fd263 "x86", > cb=cb@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 _______________________________________________ virt-tools-list mailing list email@example.com https://www.redhat.com/mailman/listinfo/virt-tools-list