On Wed, 2015-05-06 at 10:08 +0100, Ian Campbell wrote:
On Wed, 2015-05-06 at 10:24 +0200, Olaf Hering wrote:
> On Fri, May 01, Ian Campbell wrote:
>
> > Olaf, please can you use gdb to capture the stack trace so we can fix
> > this (and the other issue) properly in libxl instead of just hacking
> > around it in libvirt (which might also be appropriate for compat with
> > old libxl but shouldn't be done without also fixing libxl IMHO).
>
> The code flow was essentially like this:
>
> libxl_device_vfb_init(libxl);
> switch(libvirt->type) {
> case SDL:
> libxl_defbool_set(libxl->sdl.enable, 1);
> break;
> case VNC:
> libxl_defbool_set(libxl->vnc.enable, 1);
> break;
> }
>
> if (libvirt->os.type == HVM) {
> if (libxl_defbool_val(libxl->vnc.enable)) {
> /* do VNC things */
> } else if (libxl_defbool_val(libxl->sdl.enable)) {
> /* do SDL things */
> if (libxl_defbool_val(libxl->opengl.enable))
> /* do openGL things */
> }
> }
>
>
> The first crash was because I had SDL enabled, and the SDL case did not
> initialize the defbool for VNC. Once it did the next crash was the
> openGL part which was not initialized either.
>
> I see nothing wrong with libxl in such usage.
Please provide the actual stack trace as requested so we can see
which
code path in libxl is failing to properly initialise the defbools.
Ah, one moment, are you saying that all this code is within libvirt and
not in libxl and that the "libxl->" object here hasn't yet been passed
to a libxl function?
If so then yes it is a libvirt bug to use
libxl_defbool_val(libxl->opengl.enable) without having called set on it
first. If you passed such a thing to libxl and it crashed then that
would be a libxl bug, but it seems you aren't getting that far.
I was confused by the initial message because the assert says libxl.c,
but that's just because it is out of line, which lead to a confusing
error message. Sorry for leading the conversation down the wrong alley
way.
Ian.