The reason for this behavior was that in the invoking code we were closing all file descriptors, including 0, 1, and 2, before doing a fork/exec of the spice client. As a result the spice client obtained file descriptors with values 1 and 2 when it created its first event Trigger on start-up. As a result any output to stderr was then written to the ProcessLoop trigger's pipe, with disastrous results. (As the Trigger class is written to never expect more than one byte to be written into the pipe, an event storm on fd 1 occured, effectively starving all other input - including X Windows mouse and keyboard - from the select loop of EventSources::wait_events.)
We've fixed the problem locally by changing our invocation of spicec to leave the stdio file descriptors open. However, in the interest of defensive programming I'd suggest that the spice client do some kind of check on the stderr file descriptor before logging anything to that stream - this could be done in Application::init_logger() and enforced in Application::spice_log().
thanks
Neal Prager
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel