Re: [Xen-devel] libxl parser question

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Sun, 2012-05-06 at 22:23 +0100, Goncalo Gomes wrote:
> On Sun, 06 May 2012, Ian Campbell wrote:
> 
> > I've tried reproducing using your config file with the patch applied and
> > I can't.
> > 
> > > [...]
> > > This abort is the `default` case in the switch at xl_cmdimpl.c:736, 
> > > which gets triggered from an erroneous b_info->type with a bogus value 
> > > of 0x84 (which is neither PV nor HVM.)
> > 
> > I think it might be useful to sprinkle prints of b_info->type everywhere
> > from the call to libxl_domain_build_info_init_type up until this switch
> > statement to see if you can identify the line which is overwriting this
> > field. I couldn't spot it by eye but something in there is presumably
> > blowing off the end of a buffer or something similar.
> > 
> > You should probably also validate the initial value, which comes from
> > c_info->type, and if that is wrong trace it back to the place which sets
> > that initial value.
> 
> Running 'make install' after various attempts seems to have done it. 
> 
> I was all along under the impression that the dynamic linker would 
> pick the libxenlight in the current dir, which is why I hadn't run 
> 'make install' every so often, but did instead occasionally run 'make 
> clean all' Coming to think of it, if the DLD was to pick the library 
> from the current directory, a world of security bugs and pain would 
> ensue, but for some reason I kept expecting the behaviour to be that.

Yeah, "." is not normally in the default library lookup path for a
variety of security etc issues as you suspected.You can either use
LD_LIBRARY_PATH=stuff:other-stuff or just run make install.

Ian.


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