[Spice-devel] Spice agent and LXC

Submitted by Charles Ricketts on Nov. 28, 2014, 5:27 a.m.

Details

Message ID 547807A4.8060002@gmail.com
State New
Headers show

Not browsing as part of any series.

Commit Message

Charles Ricketts Nov. 28, 2014, 5:27 a.m.
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:

spice/server/tests/Makefile: add -lm to LDFLAGS (looks like the LIBM
line below doesn't get used?)

(hand typed diff, prone to error)


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):

$ sudo Xspice --vdagent --vdagent-exec $(which spice-vdagent)
--vdagentd-exec $(which spice-vdagentd) --disable-ticketing :0
...
Loading extension GLX
resizing surface0 to 1677216
memory space from 0x7f10bfba0010 to 0x7f10c6b9d010
memory space from 0x7f10b6b9f010 to 0x7f10beb9f010
changing surface0 to 1677216
memory spice from 0x7f10bfba0010 to 0x7f10c6b9d010
memory space from 0x7f10b6b9f010 to 0x7f10beb9f010
(EE)
(EE) Backtrace:
(EE) 0: /usr/bin/Xorg (xorg_backtrace+0x48) [0x7f10ce389c78]
(EE) 1: /usr/bin/Xorg (0x7f10ce1e1000+0x1ac969) [0x7f10ce38d969]
(EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f10cd2de000+0x10340)
[0x7f10cd2ee340]
(EE) 3: /usr/lib/x86_64-linux-gnu/libspice-server.so.1
(0x7f10c7b5d000+0x20d3c) [0x7f10c7b7dd3c]
(EE) 4: /usr/lib/x86_64-linux-gnu/libspice-server.so.1
(0x7f10c7b5d000+0x210dc) [0x7f10c7b7e0dc]
(EE) 5: /usr/lib/xorg/modules/drivers/spiceqxl_drv.so
(0x7f10c7e7a000+0x9885) [0x7f10c7e83885]
(EE) 6: /usr/lib/x86_64-linux-gnu/libspice-server.so.1
(0x7f10c7b5d000+0x22dde) [0x7f10c7b7fdde]
(EE) 7: /usr/lib/x86_64-linux-gnu/libspice-server.so.1
(spice_server_add_interface+0x3a6) [0x7f10c7ba6206]
(EE) 8: /usr/lib/xorg/modules/drivers/spiceqxl_drv.so
(0x7f10c7e7a000+0xc2a3) [0x7f10c7e862a3]
(EE) 9: /usr/bin/Xorg (AddScreen+0x71) [0x7f10ce236d41]
(EE) 10: /usr/bin/Xorg (InitOutput+0x3c8) [0x7f10ce277ce8]
(EE) 11: /usr/bin/Xorg (0x7f10ce1e1000+0x5975b) [0x7f10ce23a75b]
(EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5)
[0x7f10cbd1dec5]
(EE) 13: /usr/bin/Xorg (0x7f10ce1e1000+0x44e7e) [0x7f10ce225e77e]
(EE)
(EE) Segmentation fault at address 0xd8
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
....

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 /would/ cause some weird problems..
Reordering via ldconfig... success!

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:

--- /usr/bin/Xspice     2014-11-27 22:58:26.114824336 -0600
+++ Xspice      2014-11-27 22:58:07.722824336 -0600
 else:
     if args.vdagent_enabled and args.vdagent_launch:
         # XXX use systemd --user for this?
-        vdagentd = launch(args=[args.vdagentd_exec, '-x', '-S',
vdagentd_uds,
+        vdagentd = launch(args=[args.vdagentd_exec, '-f', '-x', '-S',
vdagentd_uds,
                           '-s', args.vdagent_virtio_path, '-u',
args.vdagent_uinput_path])
         time.sleep(1)
         # TODO wait for uinput pipe open for write

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.

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.

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`:

./configure: line 18133: syntax error near unexpected token `RANDR,'
./configure: line 18133: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)''

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.

# yum list '*x11*devel*'
Installed Packages
xorg-x11-proto-devel.noarch
xorg-x11-server-devel.x86_64
xorg-x11-xkb-utils-devel.x86_64
xorg-x11-xtrans-devel.noarch
...

#yum list '*randr*devel*'
Installed Packages
libXrandr-devel.x86_64
...

If you guys could point me in the right direction here, it'd be greatly
appreciated.

Chuck

On 11/27/2014 06:02 AM, Charles Ricketts wrote:
> 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:
>> On Wed, Nov 26, 2014 at 05:16:52PM -0600, Charles Ricketts wrote:
>>> 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.
>>>
>> Have you tried all of this without lxc to see how well/bad it works
>> without adding lxc to the mix?
>>
>> Christophe
>

Patch hide | download patch | download mbox

--- Makefile    2014-11-27 22:00:04.138824336 -0600
+++ Makefile.mod        2014-11-27 21:59:37.802824336 -0600
@@ -334,7 +334,7 @@ 
 INSTALL_STRIP_PROGRAM = $(install_sh) -c -s
 JPEG_LIBS = -ljpeg
 LD = /usr/bin/ld -m elf_x86_64
-LDFLAGS = 
+LDFLAGS = -lm
LIBM = -lm
LIBOBJS =
LIBRT = -lrt

Comments

Despite my problem with building within my VM environment, I went ahead
and attempted a Fedora LXC+Spice configuration. I'm happy to report it
was successful as well. The only change that had to be made was adding
the -f argument to the Xspice script to keep spice-vdagentd from
attempting ioctl ops on the uinput pipe created by the QXL driver. I'm
not sure why I didn't see this before, looks like I had mistakenly
forgotten to use --prefix=/usr on the vdagent source, so I was using the
distribution-provided version which doesn't have the -f option at all
and apparently doesn't print the "improper ioctl for device" error.
However, upon ensuring I was using the git versions of the vdagents and
the -f flag was added in Xspice, I was again successful!

Hooray!

Well, if nothing else, I hope this discussion helps somebody else
looking to accomplish the same task. And, even if it wasn't intended,
props to the developers for having the foresight in making the QXL
driver/Xspice and the agents flexible enough to use non-character
devices and therefore eliminating the reliance on a virtualized
environment. You guys rock!

Chuck R.

On 11/27/2014 11:27 PM, Charles Ricketts wrote:
> 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:
>
> spice/server/tests/Makefile: add -lm to LDFLAGS (looks like the LIBM
> line below doesn't get used?)
>
> (hand typed diff, prone to error)
>
> --- Makefile    2014-11-27 22:00:04.138824336 -0600
> +++ Makefile.mod        2014-11-27 21:59:37.802824336 -0600
> @@ -334,7 +334,7 @@
>  INSTALL_STRIP_PROGRAM = $(install_sh) -c -s
>  JPEG_LIBS = -ljpeg
>  LD = /usr/bin/ld -m elf_x86_64
> -LDFLAGS = 
> +LDFLAGS = -lm
> LIBM = -lm
> LIBOBJS =
> LIBRT = -lrt
>
> 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):
>
> $ sudo Xspice --vdagent --vdagent-exec $(which spice-vdagent)
> --vdagentd-exec $(which spice-vdagentd) --disable-ticketing :0
> ...
> Loading extension GLX
> resizing surface0 to 1677216
> memory space from 0x7f10bfba0010 to 0x7f10c6b9d010
> memory space from 0x7f10b6b9f010 to 0x7f10beb9f010
> changing surface0 to 1677216
> memory spice from 0x7f10bfba0010 to 0x7f10c6b9d010
> memory space from 0x7f10b6b9f010 to 0x7f10beb9f010
> (EE)
> (EE) Backtrace:
> (EE) 0: /usr/bin/Xorg (xorg_backtrace+0x48) [0x7f10ce389c78]
> (EE) 1: /usr/bin/Xorg (0x7f10ce1e1000+0x1ac969) [0x7f10ce38d969]
> (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f10cd2de000+0x10340)
> [0x7f10cd2ee340]
> (EE) 3: /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> (0x7f10c7b5d000+0x20d3c) [0x7f10c7b7dd3c]
> (EE) 4: /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> (0x7f10c7b5d000+0x210dc) [0x7f10c7b7e0dc]
> (EE) 5: /usr/lib/xorg/modules/drivers/spiceqxl_drv.so
> (0x7f10c7e7a000+0x9885) [0x7f10c7e83885]
> (EE) 6: /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> (0x7f10c7b5d000+0x22dde) [0x7f10c7b7fdde]
> (EE) 7: /usr/lib/x86_64-linux-gnu/libspice-server.so.1
> (spice_server_add_interface+0x3a6) [0x7f10c7ba6206]
> (EE) 8: /usr/lib/xorg/modules/drivers/spiceqxl_drv.so
> (0x7f10c7e7a000+0xc2a3) [0x7f10c7e862a3]
> (EE) 9: /usr/bin/Xorg (AddScreen+0x71) [0x7f10ce236d41]
> (EE) 10: /usr/bin/Xorg (InitOutput+0x3c8) [0x7f10ce277ce8]
> (EE) 11: /usr/bin/Xorg (0x7f10ce1e1000+0x5975b) [0x7f10ce23a75b]
> (EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5)
> [0x7f10cbd1dec5]
> (EE) 13: /usr/bin/Xorg (0x7f10ce1e1000+0x44e7e) [0x7f10ce225e77e]
> (EE)
> (EE) Segmentation fault at address 0xd8
> (EE)
> Fatal server error:
> (EE) Caught signal 11 (Segmentation fault). Server aborting
> ....
>
> 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 /would/ cause some weird
> problems.. Reordering via ldconfig... success!
>
> 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:
>
> --- /usr/bin/Xspice     2014-11-27 22:58:26.114824336 -0600
> +++ Xspice      2014-11-27 22:58:07.722824336 -0600
>  else:
>      if args.vdagent_enabled and args.vdagent_launch:
>          # XXX use systemd --user for this?
> -        vdagentd = launch(args=[args.vdagentd_exec, '-x', '-S',
> vdagentd_uds,
> +        vdagentd = launch(args=[args.vdagentd_exec, '-f', '-x', '-S',
> vdagentd_uds,
>                            '-s', args.vdagent_virtio_path, '-u',
> args.vdagent_uinput_path])
>          time.sleep(1)
>          # TODO wait for uinput pipe open for write
>
> 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.
>
> 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.
>
> 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`:
>
> ./configure: line 18133: syntax error near unexpected token `RANDR,'
> ./configure: line 18133: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)''
>
> 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.
>
> # yum list '*x11*devel*'
> Installed Packages
> xorg-x11-proto-devel.noarch
> xorg-x11-server-devel.x86_64
> xorg-x11-xkb-utils-devel.x86_64
> xorg-x11-xtrans-devel.noarch
> ...
>
> #yum list '*randr*devel*'
> Installed Packages
> libXrandr-devel.x86_64
> ...
>
> If you guys could point me in the right direction here, it'd be
> greatly appreciated.
>
> Chuck
>
> On 11/27/2014 06:02 AM, Charles Ricketts wrote:
>> 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:
>>> On Wed, Nov 26, 2014 at 05:16:52PM -0600, Charles Ricketts wrote:
>>>> 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.
>>>>
>>> Have you tried all of this without lxc to see how well/bad it works
>>> without adding lxc to the mix?
>>>
>>> Christophe
>
Hey,

On Thu, Nov 27, 2014 at 11:27:00PM -0600, Charles Ricketts wrote:
> 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.

Ah great to hear :)

> 
> 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.
> 
> 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`:
> 
> ./configure: line 18133: syntax error near unexpected token `RANDR,'
> ./configure: line 18133: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)''

This is defined in /usr/share/aclocal/xorg-server.m4 which is part of
the xorg-x11-server-devel package. This kind of errors happens when
building from git (and running autogen.sh), and generally don't happen
when building from tarballs and using configure.

> 
> 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.
> 
> # yum list '*x11*devel*'
> Installed Packages
> xorg-x11-proto-devel.noarch
> xorg-x11-server-devel.x86_64
> xorg-x11-xkb-utils-devel.x86_64
> xorg-x11-xtrans-devel.noarch

Ah, have you rerun autogen.sh after installing these packages?


Christophe
On Fri, Nov 28, 2014 at 12:03:59AM -0600, Charles Ricketts wrote:
> Despite my problem with building within my VM environment, I went ahead
> and attempted a Fedora LXC+Spice configuration. I'm happy to report it
> was successful as well. The only change that had to be made was adding
> the -f argument to the Xspice script to keep spice-vdagentd from
> attempting ioctl ops on the uinput pipe created by the QXL driver. I'm
> not sure why I didn't see this before, looks like I had mistakenly
> forgotten to use --prefix=/usr on the vdagent source, so I was using the
> distribution-provided version which doesn't have the -f option at all
> and apparently doesn't print the "improper ioctl for device" error.
> However, upon ensuring I was using the git versions of the vdagents and
> the -f flag was added in Xspice, I was again successful!
> 
> Hooray!
> 
> Well, if nothing else, I hope this discussion helps somebody else
> looking to accomplish the same task. And, even if it wasn't intended,
> props to the developers for having the foresight in making the QXL
> driver/Xspice and the agents flexible enough to use non-character
> devices and therefore eliminating the reliance on a virtualized
> environment. You guys rock!

Well, thanks a lot for your patience and all the investigation you made!
I'm still surprised it segfaults with the ubuntu packages. What version
of spice-server is being used there? A backtrace with debugging symbols
would still be great, I think you'd need to install the corresponding
debug packages (I forgot how to do that on ubuntu), and then try to get
a coredump or to run Xspice in gdb.

Christophe
On 11/28/2014 07:00 AM, Christophe Fergeau wrote:
> On Fri, Nov 28, 2014 at 12:03:59AM -0600, Charles Ricketts wrote:
>> Despite my problem with building within my VM environment, I went ahead
>> and attempted a Fedora LXC+Spice configuration. I'm happy to report it
>> was successful as well. The only change that had to be made was adding
>> the -f argument to the Xspice script to keep spice-vdagentd from
>> attempting ioctl ops on the uinput pipe created by the QXL driver. I'm
>> not sure why I didn't see this before, looks like I had mistakenly
>> forgotten to use --prefix=/usr on the vdagent source, so I was using the
>> distribution-provided version which doesn't have the -f option at all
>> and apparently doesn't print the "improper ioctl for device" error.
>> However, upon ensuring I was using the git versions of the vdagents and
>> the -f flag was added in Xspice, I was again successful!
>>
>> Hooray!
>>
>> Well, if nothing else, I hope this discussion helps somebody else
>> looking to accomplish the same task. And, even if it wasn't intended,
>> props to the developers for having the foresight in making the QXL
>> driver/Xspice and the agents flexible enough to use non-character
>> devices and therefore eliminating the reliance on a virtualized
>> environment. You guys rock!
>
> Well, thanks a lot for your patience and all the investigation you made!
> I'm still surprised it segfaults with the ubuntu packages. What version
> of spice-server is being used there? A backtrace with debugging symbols
> would still be great, I think you'd need to install the corresponding
> debug packages (I forgot how to do that on ubuntu), and then try to get
> a coredump or to run Xspice in gdb.
>
> Christophe
The segfault was simply a configuration error. it was dynamically
linking the distribution-provided libspice-server.so.1.8.0 rather than
the newly compiled libspice-server.so.1.9.0 due to the 1.8.0 version
having a higher precedence with ldconfig. After reordering the library
precedence to favor the new version it worked just fine.

Chuck R.
On Sat, Nov 29, 2014 at 08:34:48PM -0600, Charles Ricketts wrote:
> > Christophe
> The segfault was simply a configuration error. it was dynamically
> linking the distribution-provided libspice-server.so.1.8.0 rather than
> the newly compiled libspice-server.so.1.9.0 due to the 1.8.0 version
> having a higher precedence with ldconfig. After reordering the library
> precedence to favor the new version it worked just fine.

Unless the segfault was caused by a new symbol available in 1.9.0, but
not present in 1.8.0, this should not be happening. This could be a bug
in spice-server that was fixed in the new version, in which case it
would be good that ubuntu is aware about it so that they can fix it in
their package.

Christophe
I'm pretty sure that is actually the case. I know that I got a compilation
error at first on Ubuntu because I had forgotten to install the development
headers from the git sources. Compiling against the 1.8.0 headers in the
14.04 repositories gave me an error related to either
VD_AGENT_CLIPBOARD_MAX_SIZE_DEFAULT or VD_AGENT_CLIPBOARD_MAX_SIZE_ENV, I
forget which exactly. This symbol is in
/usr/include/spice-1/spice/vd_agent.h. If I'm looking at this correctly,
wouldn't something like this cause the problem?

In case I'm wrong, there is no debug spice-server library available on
Ubuntu 14.04 anyway. So, in order to compile one, would it be as easy as
`CFLAGS="$CFLAGS -g" make`, or something a little more intricate? I've done
simple compilations of programs I've written myself using `g++ -lm main.cpp
-o my_program,` but that's about the extent of it. I can usually get
configure scripts to work with me, but when it comes to Automake I'm
completely lost.

Chuck R.

On Mon, Dec 1, 2014 at 3:14 AM, Christophe Fergeau <cfergeau@redhat.com>
wrote:

> On Sat, Nov 29, 2014 at 08:34:48PM -0600, Charles Ricketts wrote:
> > > Christophe
> > The segfault was simply a configuration error. it was dynamically
> > linking the distribution-provided libspice-server.so.1.8.0 rather than
> > the newly compiled libspice-server.so.1.9.0 due to the 1.8.0 version
> > having a higher precedence with ldconfig. After reordering the library
> > precedence to favor the new version it worked just fine.
>
> Unless the segfault was caused by a new symbol available in 1.9.0, but
> not present in 1.8.0, this should not be happening. This could be a bug
> in spice-server that was fixed in the new version, in which case it
> would be good that ubuntu is aware about it so that they can fix it in
> their package.
>
> Christophe
>
On Mon, Dec 01, 2014 at 04:33:49AM -0600, Charles Ricketts wrote:
> I'm pretty sure that is actually the case. I know that I got a compilation
> error at first on Ubuntu because I had forgotten to install the development
> headers from the git sources. Compiling against the 1.8.0 headers in the
> 14.04 repositories gave me an error related to either
> VD_AGENT_CLIPBOARD_MAX_SIZE_DEFAULT or VD_AGENT_CLIPBOARD_MAX_SIZE_ENV, I
> forget which exactly. This symbol is in
> /usr/include/spice-1/spice/vd_agent.h. If I'm looking at this correctly,
> wouldn't something like this cause the problem?

Hmm these symbols are symbolic #defines, so will not show up in the
resulting binary, so they should not cause the issues I have in mind.
This would cause an explicit message when trying to start qemu.

> 
> In case I'm wrong, there is no debug spice-server library available on
> Ubuntu 14.04 anyway. So, in order to compile one, would it be as easy as
> `CFLAGS="$CFLAGS -g" make`, or something a little more intricate? I've done
> simple compilations of programs I've written myself using `g++ -lm main.cpp
> -o my_program,` but that's about the extent of it. I can usually get
> configure scripts to work with me, but when it comes to Automake I'm
> completely lost.

Maybe you should just file an ubuntu bug about the crash, and they may
tell you how to gather more info if they need it. I don't know if there
is a -dbg package or not for spice-server on ubuntu (but I could not
find one after a quick look).

Christophe
I just did a verification and the symbol was actually
VD_AGENT_MAX_CLIPBOARD, not that it matters all that much but perhaps
you'll know what this is and won't have to look it up and dig through git
or anything ;).

By the way, tarball sources were mentioned as being more manageable in
general. As a matter of practicality, should spice sources be compiled from
the tarballs or git? Or does it matter? FWIW, I don't know a whole lot
about git, just how to 'git clone', but I always imagined that doing so
would pull in every change up until the point it's done, regardless of
whether it's actually made it into a release or not and might break things
depending on when it's done. Generally speaking, is this a relevant concern?

Also, I suppose I'll provide a status update: I did manage to get QXL
working with GDM in Fedora 20. Ubuntu 14.04, however, is causing me
headaches. Due to a combination of its limited implementation of systemd
and/or the fact that I'm running it within an LXC container breaks the
systemd cgroup, preventing vdagentd from getting session information from
vdagent and therefore preventing it from working properly. And, since
ConsoleKit auth has been dropped in 14.04, that's out of the question as
well. Even if I were to install the Pam module, apparently using them both
in combination is frowned upon if not impossible and prone to breakage.
Nevertheless, I've moved my further questions to the Ubuntu and LXC guys
since I'm unsure exactly which system is causing the problem, but it's
clearly not Spice-related.

However, one thing that may be Spice related is the tendency for the LXC
display to hang. For example, when GDM starts in Fedora 20, it takes about
a minute and a half or so to bring up the actual login display. At first I
attributed this to Gnome Shell (I use it myself and know how slow it can be
at times), but I found that this is actually a recurring problem when stuff
moves on the screen repeatedly. One reproducible example I found was
playing a YouTube video within Spice (not even full screen). It would cause
the whole display to do the same hang for a long period of time as well.
The display would hang until the video ended (or perhaps some time after, I
didn't time it exactly) or until the Firefox close button was clicked and
after a fairly long delay (30 seconds, maybe). I would like to investigate
this as well, but I will need to figure out how to set up an alternate
display for comparison in order to be able to determine whether it's
actually Spice or not.

Charles R.

On Mon, Dec 1, 2014 at 4:33 AM, Charles Ricketts <githlar@gmail.com> wrote:

> I'm pretty sure that is actually the case. I know that I got a compilation
> error at first on Ubuntu because I had forgotten to install the development
> headers from the git sources. Compiling against the 1.8.0 headers in the
> 14.04 repositories gave me an error related to either
> VD_AGENT_CLIPBOARD_MAX_SIZE_DEFAULT or VD_AGENT_CLIPBOARD_MAX_SIZE_ENV, I
> forget which exactly. This symbol is in
> /usr/include/spice-1/spice/vd_agent.h. If I'm looking at this correctly,
> wouldn't something like this cause the problem?
>
> In case I'm wrong, there is no debug spice-server library available on
> Ubuntu 14.04 anyway. So, in order to compile one, would it be as easy as
> `CFLAGS="$CFLAGS -g" make`, or something a little more intricate? I've done
> simple compilations of programs I've written myself using `g++ -lm main.cpp
> -o my_program,` but that's about the extent of it. I can usually get
> configure scripts to work with me, but when it comes to Automake I'm
> completely lost.
>
> Chuck R.
>
> On Mon, Dec 1, 2014 at 3:14 AM, Christophe Fergeau <cfergeau@redhat.com>
> wrote:
>
>> On Sat, Nov 29, 2014 at 08:34:48PM -0600, Charles Ricketts wrote:
>> > > Christophe
>> > The segfault was simply a configuration error. it was dynamically
>> > linking the distribution-provided libspice-server.so.1.8.0 rather than
>> > the newly compiled libspice-server.so.1.9.0 due to the 1.8.0 version
>> > having a higher precedence with ldconfig. After reordering the library
>> > precedence to favor the new version it worked just fine.
>>
>> Unless the segfault was caused by a new symbol available in 1.9.0, but
>> not present in 1.8.0, this should not be happening. This could be a bug
>> in spice-server that was fixed in the new version, in which case it
>> would be good that ubuntu is aware about it so that they can fix it in
>> their package.
>>
>> Christophe
>>
>
>
The actual commit that made this change is here:
http://cgit.freedesktop.org/spice/spice-protocol/commit/spice/vd_agent.h?id=5ff3fa7080bd08392fc011175657264d57dddcec.
It's about a year old and if I'm reading the tags correctly in the
.../spice/spice repository, 0.8.0 was released March 2012. So, as far as I
can tell it would correlate. However, if you still want me to file the bug
I can do it. Though, honestly, I have a feeling that it'd get marked "Not a
bug" pretty quickly given that passing the version-matched library via
LD_LIBRARY_PATH or ldconfig works as expected.

Charles R.

On Mon, Dec 1, 2014 at 5:07 AM, Charles Ricketts <githlar@gmail.com> wrote:

> I just did a verification and the symbol was actually
> VD_AGENT_MAX_CLIPBOARD, not that it matters all that much but perhaps
> you'll know what this is and won't have to look it up and dig through git
> or anything ;).
>
> By the way, tarball sources were mentioned as being more manageable in
> general. As a matter of practicality, should spice sources be compiled from
> the tarballs or git? Or does it matter? FWIW, I don't know a whole lot
> about git, just how to 'git clone', but I always imagined that doing so
> would pull in every change up until the point it's done, regardless of
> whether it's actually made it into a release or not and might break things
> depending on when it's done. Generally speaking, is this a relevant concern?
>
> Also, I suppose I'll provide a status update: I did manage to get QXL
> working with GDM in Fedora 20. Ubuntu 14.04, however, is causing me
> headaches. Due to a combination of its limited implementation of systemd
> and/or the fact that I'm running it within an LXC container breaks the
> systemd cgroup, preventing vdagentd from getting session information from
> vdagent and therefore preventing it from working properly. And, since
> ConsoleKit auth has been dropped in 14.04, that's out of the question as
> well. Even if I were to install the Pam module, apparently using them both
> in combination is frowned upon if not impossible and prone to breakage.
> Nevertheless, I've moved my further questions to the Ubuntu and LXC guys
> since I'm unsure exactly which system is causing the problem, but it's
> clearly not Spice-related.
>
> However, one thing that may be Spice related is the tendency for the LXC
> display to hang. For example, when GDM starts in Fedora 20, it takes about
> a minute and a half or so to bring up the actual login display. At first I
> attributed this to Gnome Shell (I use it myself and know how slow it can be
> at times), but I found that this is actually a recurring problem when stuff
> moves on the screen repeatedly. One reproducible example I found was
> playing a YouTube video within Spice (not even full screen). It would cause
> the whole display to do the same hang for a long period of time as well.
> The display would hang until the video ended (or perhaps some time after, I
> didn't time it exactly) or until the Firefox close button was clicked and
> after a fairly long delay (30 seconds, maybe). I would like to investigate
> this as well, but I will need to figure out how to set up an alternate
> display for comparison in order to be able to determine whether it's
> actually Spice or not.
>
> Charles R.
>
> On Mon, Dec 1, 2014 at 4:33 AM, Charles Ricketts <githlar@gmail.com>
> wrote:
>
>> I'm pretty sure that is actually the case. I know that I got a
>> compilation error at first on Ubuntu because I had forgotten to install the
>> development headers from the git sources. Compiling against the 1.8.0
>> headers in the 14.04 repositories gave me an error related to either
>> VD_AGENT_CLIPBOARD_MAX_SIZE_DEFAULT or VD_AGENT_CLIPBOARD_MAX_SIZE_ENV, I
>> forget which exactly. This symbol is in
>> /usr/include/spice-1/spice/vd_agent.h. If I'm looking at this correctly,
>> wouldn't something like this cause the problem?
>>
>> In case I'm wrong, there is no debug spice-server library available on
>> Ubuntu 14.04 anyway. So, in order to compile one, would it be as easy as
>> `CFLAGS="$CFLAGS -g" make`, or something a little more intricate? I've done
>> simple compilations of programs I've written myself using `g++ -lm main.cpp
>> -o my_program,` but that's about the extent of it. I can usually get
>> configure scripts to work with me, but when it comes to Automake I'm
>> completely lost.
>>
>> Chuck R.
>>
>> On Mon, Dec 1, 2014 at 3:14 AM, Christophe Fergeau <cfergeau@redhat.com>
>> wrote:
>>
>>> On Sat, Nov 29, 2014 at 08:34:48PM -0600, Charles Ricketts wrote:
>>> > > Christophe
>>> > The segfault was simply a configuration error. it was dynamically
>>> > linking the distribution-provided libspice-server.so.1.8.0 rather than
>>> > the newly compiled libspice-server.so.1.9.0 due to the 1.8.0 version
>>> > having a higher precedence with ldconfig. After reordering the library
>>> > precedence to favor the new version it worked just fine.
>>>
>>> Unless the segfault was caused by a new symbol available in 1.9.0, but
>>> not present in 1.8.0, this should not be happening. This could be a bug
>>> in spice-server that was fixed in the new version, in which case it
>>> would be good that ubuntu is aware about it so that they can fix it in
>>> their package.
>>>
>>> Christophe
>>>
>>
>>
>