<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Finally got it set up in an Ubuntu VM, but I get the same segfault
    error sans-LXC. Just a note, in order to actually get it compiled
    within Ubuntu I had to make a change to a Makefile:<br>
    <br>
    spice/server/tests/Makefile: add -lm to LDFLAGS (looks like the LIBM
    line below doesn't get used?)<br>
    <br>
    (hand typed diff, prone to error)<br>
    <br>
    --- Makefile    2014-11-27 22:00:04.138824336 -0600<br>
    +++ Makefile.mod        2014-11-27 21:59:37.802824336 -0600<br>
    @@ -334,7 +334,7 @@<br>
     INSTALL_STRIP_PROGRAM = $(install_sh) -c -s <br>
     JPEG_LIBS = -ljpeg <br>
     LD = /usr/bin/ld -m elf_x86_64 <br>
    -LDFLAGS =  <br>
    +LDFLAGS = -lm <br>
    LIBM = -lm <br>
    LIBOBJS = <br>
    LIBRT = -lrt <br>
    <br>
    But, even after getting it successfully built, I get the same
    segfault as in LXC (note, no X is currently running and again this
    is hand-typed):<br>
    <br>
    $ sudo Xspice --vdagent --vdagent-exec $(which spice-vdagent)
    --vdagentd-exec $(which spice-vdagentd) --disable-ticketing :0<br>
    ...<br>
    Loading extension GLX<br>
    resizing surface0 to 1677216<br>
    memory space from 0x7f10bfba0010 to 0x7f10c6b9d010<br>
    memory space from 0x7f10b6b9f010 to 0x7f10beb9f010<br>
    changing surface0 to 1677216<br>
    memory spice from 0x7f10bfba0010 to 0x7f10c6b9d010<br>
    memory space from 0x7f10b6b9f010 to 0x7f10beb9f010<br>
    (EE)<br>
    (EE) Backtrace:<br>
    (EE) 0: /usr/bin/Xorg (xorg_backtrace+0x48) [0x7f10ce389c78]<br>
    (EE) 1: /usr/bin/Xorg (0x7f10ce1e1000+0x1ac969) [0x7f10ce38d969]<br>
    (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0
    (0x7f10cd2de000+0x10340) [0x7f10cd2ee340]<br>
    (EE) 3: /usr/lib/x86_64-linux-gnu/libspice-server.so.1
    (0x7f10c7b5d000+0x20d3c) [0x7f10c7b7dd3c]<br>
    (EE) 4: /usr/lib/x86_64-linux-gnu/libspice-server.so.1
    (0x7f10c7b5d000+0x210dc) [0x7f10c7b7e0dc]<br>
    (EE) 5: /usr/lib/xorg/modules/drivers/spiceqxl_drv.so
    (0x7f10c7e7a000+0x9885) [0x7f10c7e83885]<br>
    (EE) 6: /usr/lib/x86_64-linux-gnu/libspice-server.so.1
    (0x7f10c7b5d000+0x22dde) [0x7f10c7b7fdde]<br>
    (EE) 7: /usr/lib/x86_64-linux-gnu/libspice-server.so.1
    (spice_server_add_interface+0x3a6) [0x7f10c7ba6206]<br>
    (EE) 8: /usr/lib/xorg/modules/drivers/spiceqxl_drv.so
    (0x7f10c7e7a000+0xc2a3) [0x7f10c7e862a3]<br>
    (EE) 9: /usr/bin/Xorg (AddScreen+0x71) [0x7f10ce236d41]<br>
    (EE) 10: /usr/bin/Xorg (InitOutput+0x3c8) [0x7f10ce277ce8]<br>
    (EE) 11: /usr/bin/Xorg (0x7f10ce1e1000+0x5975b) [0x7f10ce23a75b]<br>
    (EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5)
    [0x7f10cbd1dec5]<br>
    (EE) 13: /usr/bin/Xorg (0x7f10ce1e1000+0x44e7e) [0x7f10ce225e77e]<br>
    (EE)<br>
    (EE) Segmentation fault at address 0xd8<br>
    (EE)<br>
    Fatal server error:<br>
    (EE) Caught signal 11 (Segmentation fault). Server aborting<br>
    ....<br>
    <br>
    Kind of glad I hand typed this, because I may have found the
    error.... it's using the distribution-provided library from
    /usr/lib/x86_64-linux-gnu/libspice-server.so.1 instead of
    /usr/lib/libspice-server.so.1, that <i>would</i> cause some weird
    problems.. Reordering via ldconfig... success!<br>
    <br>
    I actually got it fully working within Ubuntu. Using `Xspice
    --disable-ticketing --vdagent --vdagentd-exec $(which
    spice-vdagentd) --vdagent-exec $(which spice-vdagent)`. I had to
    make a modification to the Xspice script in order to get it working
    properly:<br>
    <br>
    --- /usr/bin/Xspice     2014-11-27 22:58:26.114824336 -0600<br>
    +++ Xspice      2014-11-27 22:58:07.722824336 -0600<br>
     else:<br>
         if args.vdagent_enabled and args.vdagent_launch:<br>
             # XXX use systemd --user for this?<br>
    -        vdagentd = launch(args=[args.vdagentd_exec, '-x', '-S',
    vdagentd_uds,<br>
    +        vdagentd = launch(args=[args.vdagentd_exec, '-f', '-x',
    '-S', vdagentd_uds,<br>
                               '-s', args.vdagent_virtio_path, '-u',
    args.vdagent_uinput_path])<br>
             time.sleep(1)<br>
             # TODO wait for uinput pipe open for write<br>
    <br>
    This simply adds the -f parameter to spice-vdagentd since
    /tmp/xspice-uinput is a pipe and not a character devices and,
    therefore, "fake." Without the parameter, spice-vdagend (pretty sure
    it was vdagentd) exits complaining about a bad ioctl. Using the
    modified Xspice allows me to copy/paste and automatic resolution
    switching.<br>
    <br>
    Getting it working with Xspice is definitely an accomplishment and I
    now know the caveats I need to fix within my LXC container. But
    first, my LXC setup depends on X starting with the qxlspice settings
    -- moving spiceqxl.xorg.conf to xorg.conf. In order to accomplish
    this I added the undocumented xorg.conf options:
    "SpiceVdagentEnabled" "0", "SpiceVdagentVirtioPath"
    "/tmp/xspice-virtio", "SpiceVdagentUinputPath" "/tmp/xspice-uinput"
    (taken from xf86-video-qxl/src/qxl_driver.c). Now I simply need to
    figure out how to get spice-vdagent and spice-vdagentd to start up
    alongside it, but that's another problem for another day. Overall, a
    huge success.<br>
    <br>
    But now, for Fedora. I'm unable to even get the QXL driver compiled
    for Fedora, unfortunately. I hit the following error when running
    `make`:<br>
    <br>
    ./configure: line 18133: syntax error near unexpected token `RANDR,'<br>
    ./configure: line 18133: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)''<br>
    <br>
    Keep in mind, this is my first experience with Fedora, but I've
    installed every x11 devel and xrandr devel package I can find. I
    even used advice I found on another forum to use `yum groupinstall
    "X11 Development Files"` (or some similar group name) to no avail.
    Oddly enough, I didn't have any issues with with compiling within my
    LXC container, but I'm not sure all the steps I took to set that up
    quite honestly. I even compared my installed packages with those
    from my LXC container, and they seem the same.<br>
    <br>
    # yum list '*x11*devel*'<br>
    Installed Packages<br>
    xorg-x11-proto-devel.noarch<br>
    xorg-x11-server-devel.x86_64<br>
    xorg-x11-xkb-utils-devel.x86_64<br>
    xorg-x11-xtrans-devel.noarch<br>
    ...<br>
    <br>
    #yum list '*randr*devel*'<br>
    Installed Packages<br>
    libXrandr-devel.x86_64<br>
    ...<br>
    <br>
    If you guys could point me in the right direction here, it'd be
    greatly appreciated.<br>
    <br>
    Chuck<br>
    <br>
    <div class="moz-cite-prefix">On 11/27/2014 06:02 AM, Charles
      Ricketts wrote:<br>
    </div>
    <blockquote cite="mid:547712ED.5000400@gmail.com" type="cite">
      <pre wrap="">Well, I have Spice working perfectly fine in a Windows install. However,
seeing as that's not pertinent to the Linux side of things I went ahead
and installed Ubuntu 14.04 in Qemu and, as expected, everything worked.
I didn't bother with the git sources in this install, because I was 99%
sure it was going to work anyway. I don't have a Fedora ISO lying around
to test it with, but I imagine that the results would be the same.

However, I don't think that even this is pertinent to the problem. The
reason I think this is because Qemu acts as the Spice server if I am
correct. Qemu relays information from a network socket assigned on the
command line to the virtualized serial port and vice versa. Since an LXC
installation is sans-Qemu server then I must use Xspice in order to take
the place of Qemu and act as a Spice server in order to relay
information between the agents/QXL driver and the Spice client. So,
testing it within Qemu doesn't really reflect the problem at all. Beyond
Qemu, there's really no way to test it sans-LXC. Actually, now that I
think about it I may be able to run Xspice directly within a VM and then
attempt to connect to it... I'll try that out later on and let you know
how/if that works out. I may have to get that Fedora ISO after all just
to broaden the test cases.

I realize that I'm effectively attempting to use Spice outside of normal
circumstances. However, the way that Xspice behaves -- such as creating
its own versions of the virtio port (as a socket rather than a character
device) and uinput (as a pipe) and attempting to destroy any existing
versions of those files -- leads me to believe that Xspice was almost
built for the purpose even if not intentionally. And, as I had said
before, I got it mostly working in a Fedora LXC container (only lacking
client functionality, which is why I asked for input in the first place ;).

I would like to be able to provide a stack trace of the segfault I get
in the Ubuntu LXC, but I'm unsure how to compile the sources with
debugging symbols. Any help in that respect?

On 11/27/2014 03:50 AM, Christophe Fergeau wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On Wed, Nov 26, 2014 at 05:16:52PM -0600, Charles Ricketts wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Yes, I had seen those options. That was part of why I was asking about the
ucds socket. I found now that the ucds socket is used to talk to multiple
agents. I have tried both setting each argument to specify the paths of
each piece (ucds socket, uinput, and virtio port) and letting Xspice set
them up automatically. Xspice by default re-creates these devices as
sockets and pipes, so it seems that Xspice is actually ideal for this
purpose; there is no need to create the devices by hand. However, any way
it's done even with the newest sources results in the same thing. In the
Fedora LXC under Ubuntu 14.04, I get a display but no agent functionality
for some reason even though the same ucds port is used by both agentd and
agent. In an Ubuntu 14.04 LXC container I can't even get X to start via the
Xspice script or a direct call to X because it segfaults when using the
spiceqxl driver.

There also appears to be no difference between letting the Xspice script
start the agents or starting the agents by hand, which isn't unexpected.

</pre>
        </blockquote>
        <pre wrap="">Have you tried all of this without lxc to see how well/bad it works
without adding lxc to the mix?

Christophe
</pre>
      </blockquote>
      <pre wrap="">

</pre>
    </blockquote>
    <br>
  </body>
</html>