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

[Daniel P. Berrangé]

On Fri, Feb 23, 2018 at 02:15:53PM -0500, Cole Robinson wrote:
> 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

FYI, we've long had a problem in CI where virt-manager test suite will
randomly SEGV about 20% of the time. So I wonder if this might have been
the cause of that too.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|