Re: [Xen-devel] segv in osevent_release_nexus with libxl backend to libvirt

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-11-26 at 15:40 +0000, Ian Campbell wrote:
> (adding xen-devel which I forgot first time around)
> 
> On Wed, 2014-11-26 at 15:21 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("segv in osevent_release_nexus with libxl backend to 
> > libvirt"):
> > > I'm seeing quite a few of these when shutting down domains:
> > ...
> > > This is on ARM but I don't think this appears to be arch specific at
> > > first glance. The bit from virObjectUnref->SEGV appears to be the same
> > > each time, but the leadin can be different:
> > ...       
> > > Perhaps that's just an artefact of the reference counting dropping to to
> > > zero in a different order not really relevant.
> > 
> > Having looked at this, I think that this is because libxl_ctx_free is
> > being reentered on the same ctx.
> > 
> > Below is a tiny patch to libxl which ought to crash on this earlier.
> > Ian C, can you try it ?  If this catches anything it will probably
> > show a path in libvirt where a libxl call is made without taking a ref
> > on the vm object.
> 
> With this I am seeing:
>         Program received signal SIGSEGV, Segmentation fault.
>         0xb16d2fd8 in osevent_release_nexus (gc=0xbefff51c, 
> nexi_idle=0x2a09701c, nexus=0x0) at libxl_event.c:119
>         119   libxl_event.c: No such file or directory.
>         (gdb) bt
>         #0  0xb16d2fd8 in osevent_release_nexus (gc=0xbefff51c, 
> nexi_idle=0x2a09701c, nexus=0x0) at libxl_event.c:119
>         #1  0xb16d3b14 in osevent_hook_pre_release (nexus=0x2a097074, 
> nexi_idle=<optimized out>, ev=0x2a097060, gc=0xbefff51c) at libxl_event.c:149
>         #2  libxl__ev_fd_deregister (gc=0xbefff51c, ev=0x2a097060) at 
> libxl_event.c:231
>         #3  0xb16a4858 in libxl_ctx_free (ctx=0x2a096fa8) at libxl.c:168
>         #4  0xb171814e in libxlDomainObjPrivateDispose () from 
> /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
>         #5  0xb6c69176 in virObjectUnref () from /opt/libvirt/lib/libvirt.so.0
>         #6  0xb1717696 in libxlDomainObjTimerEventHookInfoFree () from 
> /opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
>         #7  0xb6c3eae4 in virEventPollCleanupTimeouts () from 
> /opt/libvirt/lib/libvirt.so.0
>         #8  0xb6c3f0f2 in virEventPollRunOnce () from 
> /opt/libvirt/lib/libvirt.so.0
>         #9  0xb6c3d2fc in virEventRunDefaultImpl () from 
> /opt/libvirt/lib/libvirt.so.0
>         #10 0x2a05495a in virNetServerRun ()
>         #11 0x2a01297c in main ()
>         
> 
> I don't think this is what you were hoping for :-/

I don't know if this helps but on the 3 occasions I've just looked at
the ev passed to libxl__ev_fd_deregister contains an fd which
corresponds to a still open handle on /dev/xen/evtchn.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel