Re: [Spice-devel] MacOS Client Crashing upon Connection to graphic Server is established

2017-12-02 Thread Christophe de Dinechin
Hi Jannik,


Sorry for the belated response, but the macOS client needs a bit of
love.

First, I downloaded the same RemoteViewer you are using, and connected
to a few local virtual machines successfully, if slowly. I am running
High Sierra, but I don't believe it matters in that specific context.

To verify that, I installed it inside a clean macOS Sierra VM, and from
there, I was able to connect to other guests without much trouble.

So the bundle itself seems relatively sane. This means that we may need
to spend a little more time investigating your case. Are you comfortable
rebuilding a spice client yourself?

If so, I tried to document two ways to build a SPICE client here:
https://aspiceodyssey.wordpress.com/2017/12/01/building-spice-client-for-macos/

If that works for you, I'd be happy to attempt to debug your problem.


Thanks
Christophe

Jannik Adam writes:

> Hello Spice Dev-Team,
>
> in order to connect to a virtual desktop hosted on a university system
> using "Red Head Virtualization", I installed the bundled Spice Version
> for macOS from your Site (https://www.spice-space.org/osx-client.html).
>
> The initial connection to the VM seams to Work, but every time the Text
> on the Black screen
>
> "Connecting to Graphic Server" switches to "Connected to Graphic Server"
>
> the Remote Viewer stops listening to any kind of interaction. I even had
> to kill the process using the Activity Monitor...
> Please note, that the connection is Working on a Windows Client, so the
> Server side seams OK.
>
> To describe the situation in a nutshell:
>
> I used the bundled *RemoteViewer* in *Version 0.5.7*
> on *MacOS 10.12.6* (Sierra) (16G29)
> on Hardware Modell *MacBookPro11,3*
>
> I tried to connect to a *Remote Server* running *Red Head Virtualization
> *The *VM's* I tried to connect to are running*XUbuntu 16.04*, *CentOS 7*
> and *Windows 10*
>
> *After connection to the Graphic Server* is established,**the app *stops
> reacting to any kind of Input*.*
> *There is *no problems* connecting to those VM's with the *Windows Client*.
>
> Since i didn't found any obvious File that screamed "Log File", and in
> lack of anything else useful, I used the Activity Monitor to sample the
> process (that by the way didn't got any additional processing time since
> the hangup) and attached the Result onto this Mail. It contains a
> StackTrace that is hopefully helpful in some way.
>
> I would appreciate any Help you can offer me.
> If you need additional Informations or retests, feel free to contact me.
>
> Thank you in advanced.
>
> Regards,
>
> Jannik Adam
>
>
> **
>
>
> Sampling process 2733 for 3 seconds with 1 millisecond of run time between 
> samples
> Sampling completed, processing symbols...
> Analysis of sampling RemoteViewer-bin (pid 2733) every 1 millisecond
> Process: RemoteViewer-bin [2733]
> Path:
> /Applications/RemoteViewer.app/Contents/MacOS/RemoteViewer-bin
> Load Address:0x10a53d000
> Identifier:  org.virt-manager.remote-viewer
> Version: 0.5.7 (0.5.7)
> Code Type:   X86-64
> Parent Process:  ??? [1]
>
> Date/Time:   2017-10-18 19:31:24.273 +0200
> Launch Time: 2017-10-18 19:13:38.275 +0200
> OS Version:  Mac OS X 10.12.6 (16G29)
> Report Version:  7
> Analysis Tool:   /usr/bin/sample
> 
>
> Call graph:
> 2551 Thread_264357   DispatchQueue_1: com.apple.main-thread  (serial)
> + 2551 start  (in RemoteViewer-bin) + 52  [0x10a548454]
> +   2551 main  (in RemoteViewer-bin) + 1588  [0x10a55c494]
> + 2551 gtk_main  (in libgtk-quartz-2.0.0.dylib) + 176  [0x10a68ec10]
> +   2551 g_main_loop_run  (in libglib-2.0.0.dylib) + 287  
> [0x10b872fbf]
> + 2551 g_main_context_iterate  (in libglib-2.0.0.dylib) + 421  
> [0x10b8719c5]
> +   2551 poll_func  (in libgdk-quartz-2.0.0.dylib) + 181  
> [0x10b121d75]
> + 2551 -[NSApplication(NSEvent) 
> _nextEventMatchingEventMask:untilDate:inMode:dequeue:]  (in AppKit) + 2796  
> [0x7fff9e0857ee]
> +   2551 _DPSNextEvent  (in AppKit) + 1120  [0x7fff9d909a54]
> + 2551 _BlockUntilNextEventMatchingListInModeWithFilter  
> (in HIToolbox) + 71  [0x7fff9f370b26]
> +   2551 ReceiveNextEventCommon  (in HIToolbox) + 432  
> [0x7fff9f370cf1]
> + 2551 RunCurrentEventLoopInMode  (in HIToolbox) + 
> 240  [0x7fff9f370ebc]
> +   2551 CFRunLoopRunSpecific  (in CoreFoundation) + 
> 420  [0x7fff9fe10114]
> + 2551 __CFRunLoopRun  (in CoreFoundation) + 1361 
>  [0x7fff9fe108c1]
> +   2551 __CFRunLoopServiceMachPort  (in 
> CoreFoundation) + 212  [0x7fff9fe11434]
> + 2551 mach_msg  (in libsystem_kernel.dylib) 
> + 55  [0x7fffb56be797]
> +   2551 mach_msg_trap  (in 
> libsystem_kernel.dylib) + 10  [0x7fffb56bf34a]
> 2551 Thread_264392
> + 2551 

[Spice-devel] MacOS Client Crashing upon Connection to graphic Server is established

2017-10-19 Thread Jannik Adam

Hello Spice Dev-Team,

in order to connect to a virtual desktop hosted on a university system 
using "Red Head Virtualization", I installed the bundled Spice Version 
for macOS from your Site (https://www.spice-space.org/osx-client.html).


The initial connection to the VM seams to Work, but every time the Text 
on the Black screen


"Connecting to Graphic Server" switches to "Connected to Graphic Server"

the Remote Viewer stops listening to any kind of interaction. I even had 
to kill the process using the Activity Monitor...
Please note, that the connection is Working on a Windows Client, so the 
Server side seams OK.


To describe the situation in a nutshell:

I used the bundled *RemoteViewer* in *Version 0.5.7*
on *MacOS 10.12.6* (Sierra) (16G29)
on Hardware Modell *MacBookPro11,3*

I tried to connect to a *Remote Server* running *Red Head Virtualization
*The *VM's* I tried to connect to are running*XUbuntu 16.04*, *CentOS 7* 
and *Windows 10*


*After connection to the Graphic Server* is established,**the app *stops 
reacting to any kind of Input*.*

*There is *no problems* connecting to those VM's with the *Windows Client*.

Since i didn't found any obvious File that screamed "Log File", and in 
lack of anything else useful, I used the Activity Monitor to sample the 
process (that by the way didn't got any additional processing time since 
the hangup) and attached the Result onto this Mail. It contains a 
StackTrace that is hopefully helpful in some way.


I would appreciate any Help you can offer me.
If you need additional Informations or retests, feel free to contact me.

Thank you in advanced.

Regards,

Jannik Adam


**


Sampling process 2733 for 3 seconds with 1 millisecond of run time between 
samples
Sampling completed, processing symbols...
Analysis of sampling RemoteViewer-bin (pid 2733) every 1 millisecond
Process: RemoteViewer-bin [2733]
Path:/Applications/RemoteViewer.app/Contents/MacOS/RemoteViewer-bin
Load Address:0x10a53d000
Identifier:  org.virt-manager.remote-viewer
Version: 0.5.7 (0.5.7)
Code Type:   X86-64
Parent Process:  ??? [1]

Date/Time:   2017-10-18 19:31:24.273 +0200
Launch Time: 2017-10-18 19:13:38.275 +0200
OS Version:  Mac OS X 10.12.6 (16G29)
Report Version:  7
Analysis Tool:   /usr/bin/sample


Call graph:
2551 Thread_264357   DispatchQueue_1: com.apple.main-thread  (serial)
+ 2551 start  (in RemoteViewer-bin) + 52  [0x10a548454]
+   2551 main  (in RemoteViewer-bin) + 1588  [0x10a55c494]
+ 2551 gtk_main  (in libgtk-quartz-2.0.0.dylib) + 176  [0x10a68ec10]
+   2551 g_main_loop_run  (in libglib-2.0.0.dylib) + 287  [0x10b872fbf]
+ 2551 g_main_context_iterate  (in libglib-2.0.0.dylib) + 421  
[0x10b8719c5]
+   2551 poll_func  (in libgdk-quartz-2.0.0.dylib) + 181  
[0x10b121d75]
+ 2551 -[NSApplication(NSEvent) 
_nextEventMatchingEventMask:untilDate:inMode:dequeue:]  (in AppKit) + 2796  
[0x7fff9e0857ee]
+   2551 _DPSNextEvent  (in AppKit) + 1120  [0x7fff9d909a54]
+ 2551 _BlockUntilNextEventMatchingListInModeWithFilter  
(in HIToolbox) + 71  [0x7fff9f370b26]
+   2551 ReceiveNextEventCommon  (in HIToolbox) + 432  
[0x7fff9f370cf1]
+ 2551 RunCurrentEventLoopInMode  (in HIToolbox) + 240  
[0x7fff9f370ebc]
+   2551 CFRunLoopRunSpecific  (in CoreFoundation) + 
420  [0x7fff9fe10114]
+ 2551 __CFRunLoopRun  (in CoreFoundation) + 1361  
[0x7fff9fe108c1]
+   2551 __CFRunLoopServiceMachPort  (in 
CoreFoundation) + 212  [0x7fff9fe11434]
+ 2551 mach_msg  (in libsystem_kernel.dylib) + 
55  [0x7fffb56be797]
+   2551 mach_msg_trap  (in 
libsystem_kernel.dylib) + 10  [0x7fffb56bf34a]
2551 Thread_264392
+ 2551 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fffb57b108d]
+   2551 _pthread_start  (in libsystem_pthread.dylib) + 286  
[0x7fffb57b1887]
+ 2551 _pthread_body  (in libsystem_pthread.dylib) + 180  
[0x7fffb57b193b]
+   2551 g_thread_proxy  (in libglib-2.0.0.dylib) + 90  [0x10b89490a]
+ 2551 coroutine_thread  (in libspice-client-glib-2.0.8.dylib) + 71 
 [0x10ab9bef7]
+   2551 spice_channel_coroutine  (in 
libspice-client-glib-2.0.8.dylib) + 9645  [0x10ab7a00d]
+ 2551 g_coroutine_socket_wait  (in 
libspice-client-glib-2.0.8.dylib) + 169  [0x10ab7c599]
+   2551 coroutine_yield  (in libspice-client-glib-2.0.8.dylib) 
+ 131  [0x10ab9bdc3]
+ 2551 g_cond_wait  (in libglib-2.0.0.dylib) + 131  
[0x10b8afae3]
+   2551 _pthread_cond_wait  (in libsystem_pthread.dylib) + 
847  [0x7fffb57b2881]
+ 2551 _pthread_mutex_lock_wait  (in 
libsystem_pthread.dylib) + 100  [0x7fffb57b1dfa]
+