[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] libxl: cannot start guest

On Tue, 2012-05-22 at 15:03 +0100, Christoph Egger wrote:
> On 05/22/12 15:21, Ian Campbell wrote:
> > On Tue, 2012-05-22 at 14:18 +0100, Christoph Egger wrote:
> >> I thinkIn xs_talkv() something must fail.
> >>
> >>> The only thing which springs to mind is that it may generate an
> >>> @IntroduceDomain watch event. However xl is single threaded so we won't
> >>> process that event until we unwind to whichever point we do an event
> >>> loop iteration, in which case the corruption would have to happen later
> >>> than right after xs_introduce_domain().
> >>>
> >>> Did you manage to determine if "Bad file descriptor" was due to it being
> >>> closed vs. the value being corrupted?
> >>
> >> My suspicion is that
> >>
> >>    if (msg.type != type)
> >>
> >> in xs_talkv() is true.
> >>
> > 
> > Yes, that definitely seems worth investigating.
> Ok, I got it.
> xenstored crashes due to dereferencing NULL pointer.

Huh, xenstore has materially changed for quite a while (since February).

> In xenstored_domain.c, map_interface()  *xcg_handle is NULL
> and in xc_gnttab.c, xc_gnttab_map_grant_ref() it is dereferenced.

This comes from 24757:aae516b78fce. Diego and Alex aren't around any
more but CCing Daniel in case he remembers anything.

I guess the original xc_gnttab_open which sets *xcg_handle is failing
for you, I suppose that is to be expected on NetBSD? Either way it
should still work after this has failed.

All the >= checks on *xcg_handle seem wrong to me. Really they should be
checking != NULL, since otherwise they don't actually discriminate the
two cases! Does making that change help?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.