From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [libvirt test] 58119: regressions - FAIL Date: Tue, 23 Jun 2015 12:53:25 -0600 Message-ID: <5589AB25.1040104@suse.com> References: <1433755348.7108.402.camel@citrix.com> <20150615143055.GA3393@perard.uk.xensource.com> <1434640728.28264.46.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1434640728.28264.46.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Anthony PERARD Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 06/18/2015 09:18 AM, Ian Campbell wrote: > On Mon, 2015-06-15 at 15:30 +0100, Anthony PERARD wrote: >> The "No response from client ..." appear only on armhf as far as I can >> tell. > Indeed, and I just noticed while developing osstest for arm64 that the > daemon is segfaulting, and we even managed to collect a core dump, not > this time but in: > > http://logs.test-lab.xenproject.org/osstest/logs/58693/test-armhf-armhf-libvirt/info.html > > Although the core and the build stuff is all there it was a bit easier > to just install gdb on the arm64 system in my hands, it reports: > > Program terminated with signal SIGSEGV, Segmentation fault. > #0 malloc_consolidate (av=av@entry=0x7fa0000020) at malloc.c:4151 > 4151 malloc.c: No such file or directory. > (gdb) bt > #0 malloc_consolidate (av=av@entry=0x7fa0000020) at malloc.c:4151 > #1 0x0000007faf2adc50 in _int_malloc (av=av@entry=0x7fa0000020, bytes=bytes@entry=1100) at malloc.c:3423 > #2 0x0000007faf2afc20 in __GI___libc_malloc (bytes=bytes@entry=1100) at malloc.c:2891 > #3 0x0000007faf2b0580 in __GI___libc_realloc (oldmem=0x0, bytes=1100) at malloc.c:2972 > #4 0x0000007faf434d98 in virReallocN () from /usr/local/lib/libvirt.so.0 > #5 0x0000007faf438f34 in virBufferGrow () from /usr/local/lib/libvirt.so.0 > #6 0x0000007faf4397b8 in virBufferVasprintf () from /usr/local/lib/libvirt.so.0 > #7 0x0000007faf439700 in virBufferAsprintf () from /usr/local/lib/libvirt.so.0 > #8 0x0000007faf51b7f0 in virDomainObjFormat () from /usr/local/lib/libvirt.so.0 > #9 0x0000007faf51c078 in virDomainSaveStatus () from /usr/local/lib/libvirt.so.0 Did your libvirt fix help here too? libxlDomainSetVcpuAffinities() is called prior to virDomainSaveStatus, and may have freed some of the virDomainObj's memory. Regards, Jim > #10 0x0000007fac510d88 in libxlDomainStart () from /usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so > #11 0x0000007fac5136c4 in libxlDomainCreateXML () from /usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so > #12 0x0000007faf5977c0 in virDomainCreateXML () from /usr/local/lib/libvirt.so.0 > #13 0x00000055887730c8 in remoteDispatchDomainCreateXML () > #14 0x0000005588772fb8 in remoteDispatchDomainCreateXMLHelper () > #15 0x00000055887cb694 in virNetServerProgramDispatchCall () > #16 0x00000055887cb220 in virNetServerProgramDispatch () > #17 0x00000055887c2810 in virNetServerProcessMsg () > #18 0x00000055887c2910 in virNetServerHandleJob () > #19 0x0000007faf4ba738 in virThreadPoolWorker () from /usr/local/lib/libvirt.so.0 > #20 0x0000007faf4b989c in virThreadHelper () from /usr/local/lib/libvirt.so.0 > #21 0x0000007faf388e34 in start_thread (arg=0x7fae6540c0) at pthread_create.c:311 > #22 0x0000007faf2ff7c0 in clone () at ../ports/sysdeps/unix/sysv/linux/aarch64/nptl/../clone.S:96 > >