Re: [VirtualGL-Users] server have multi GPUs not connected to physical screen

[DRC <dco...@us...>]

I tried but was unable to reproduce any failure with the RealVNC Viewer.
 Please provide the information I requested in my previous message.


On 2/21/17 4:34 PM, Wei Liu wrote:
> Thanks DRC for the information. With all the constraints in our compute
> environment, I do want to debug that issue. Here are the log of that
> session (may not be helpful), and I will try to follow the debug steps
> and put it here. 
> 
> //////// crash log ///////////////////////
> 
> /02/2017 14:51:09 Got connection from client 159.70.104.60____
> 
> 21/02/2017 14:51:09   (other clients 159.70.87.121)____
> 
> 21/02/2017 14:51:09 Using protocol version 3.8____
> 
> 21/02/2017 14:51:12 Full-control authentication enabled for
> 159.70.104.60____
> 
> 21/02/2017 14:51:12 Enabling full-color cursor updates for client
> 159.70.104.60____
> 
> 21/02/2017 14:51:12 rfbProcessClientNormalMessage: ignoring unknown
> encoding -223 (ffffff21)____
> 
> 21/02/2017 14:51:12 Using ZRLE encoding for client 159.70.104.60____
> 
> 21/02/2017 14:51:12 rfbProcessClientNormalMessage: ignoring unknown
> encoding 15 (f)____
> 
> 21/02/2017 14:51:12 Pixel format for client 159.70.104.60
> <http://159.70.104.60/>:____
> 
> 21/02/2017 14:51:12   8 bpp, depth 8____
> 
> 21/02/2017 14:51:12   uses a colour map (not true colour).____
> 
> 21/02/2017 14:51:13 Pixel format for client 159.70.104.60
> <http://159.70.104.60/>:____
> 
> 21/02/2017 14:51:13   32 bpp, depth 24, little endian____
> 
> 21/02/2017 14:51:13   true colour: max r 255 g 255 b 255, shift r 16 g 8
> b 0____
> 
> 21/02/2017 14:51:13   no translation needed____
> 
> 21/02/2017 14:51:13 Enabling full-color cursor updates for client
> 159.70.104.60____
> 
> 21/02/2017 14:51:13 rfbProcessClientNormalMessage: ignoring unknown
> encoding -223 (ffffff21)____
> 
> 21/02/2017 14:51:13 Using hextile encoding for client 159.70.104.60____
> 
> 21/02/2017 14:51:13 rfbProcessClientNormalMessage: ignoring unknown
> encoding 15 (f)____
> 
> 21/02/2017 15:06:44 rfbProcessClientNormalMessage: read: Connection
> timed out____
> 
> 21/02/2017 15:06:44 Client 159.70.87.121 gone____
> 
> 21/02/2017 15:06:44 Statistics:____
> 
> 21/02/2017 15:06:44   key events received 686, pointer events 136033____
> 
> 21/02/2017 15:06:44   framebuffer updates 21954, rectangles 62990, bytes
> -171025480____
> 
> 21/02/2017 15:06:44     cursor shape updates 1581, bytes 3577869____
> 
> 21/02/2017 15:06:44     raw rectangles 1, bytes 17292____
> 
> 21/02/2017 15:06:44     copyRect rectangles 1696, bytes 27136____
> 
> 21/02/2017 15:06:44     hextile rectangles 59711, bytes -174662874____
> 
> 21/02/2017 15:06:44____
> 
> (nautilus:80266): Gdk-WARNING **: nautilus: Fatal IO error 11 (Resource
> temporarily unavailable) on X server :4.____
> 
> __ __
> 
> __ __
> 
> (gnome-terminal:80262): Gdk-WARNING **: gnome-terminal: Fatal IO error
> 11 (Resource temporarily unavailable) on X server :4.____
> 
> __ __
> 
> XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server
> ":4"____
> 
> __ __
> 
> (gnome-settings-daemon:80264): Gdk-WARNING **: gnome-settings-daemon:
> Fatal IO error 11 (Resource temporarily unavailable) on X server :4.____
> 
> __ __
> 
>       after 120 requests (119 known processed) with 0 events remaining.____
> 
> Window manager warning: Fatal IO error 11 (Resource temporarily
> unavailable) on display ':4'.____
> 
> __ __
> 
> (gnome-panel:80263): Gdk-WARNING **: gnome-panel: Fatal IO error 11
> (Resource temporarily unavailable) on X server :4.____
> 
> 
> On Tue, Feb 21, 2017 at 5:25 PM, DRC <dco...@us...
> <mailto:dco...@us...>> wrote:
> 
>     Definitely should not be happening.  Since it's likely related to
>     TurboVNC, my suggestion would be to build the TurboVNC Server from
>     source and include debugging information in the build:
> 
>         sudo apt-get install gcc make git cmake libpam0g-dev libsm-dev
>     libice-dev libxext-dev libssl-dev
>         git clone https://github.com/TurboVNC/turbovnc.git
>     <https://github.com/TurboVNC/turbovnc.git>
>         cd turbovnc
>         mkdir build
>         cd build
>         cmake -G"Unix Makefiles" -DTVNC_BUILDNATIVE=0 -DTVNC_BUILDJAVA=0
>     -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
>         make
> 
>     Now launch the server with:
> 
>         ulimit -c 10000000
>         bin/vncserver -debug
> 
>     When the server crashes, it should leave a core file.  Load that core
>     file into gdb:
> 
>         gdb bin/Xvnc {core file}
> 
>     Type 'where' in gdb to print a stack trace.
> 
>     Create an issue in the TurboVNC GitHub tracker:
>     https://github.com/TurboVNC/turbovnc/issues/new
>     <https://github.com/TurboVNC/turbovnc/issues/new>
> 
>     and post the following:
> 
>         -- The stack trace you obtained above
>         -- The console output from the TurboVNC Server
>         -- What version of the RealVNC Viewer you were using (example:
>     4.1.2)
>         -- What client O/S you were using (examples: Windows 7, iOS 9, macOS
>     Sierra)
>         -- What RFB encoding you were using (examples: Hextile, ZRLE)
> 
>     All of that aside, while it is a bug for the RealVNC Viewer to crash the
>     TurboVNC Server, and I definitely want to fix that bug, I also cannot
>     recommend using the RealVNC Viewer.  The TurboVNC Viewer will be
>     necessary in order to achieve full performance with our server.
> 
> 
>     On 2/21/17 4:02 PM, Wei Liu wrote:
>     > Jason, DRC,
>     >
>     > The vnc session I created with TurboVNC crashes a few times. Can it be
>     > caused by my realVNC viewer? (seems hard to believe an incompatible
>     > viewer crashes the session) I haven't got a chance to use TurboVNC
>     > viewer due to other constraints.
>     >
>     > How to debug that crashes? I can put more information if I know how.
>     >
>     > I did run some OpenGL applications in the session. Not sure if it is
>     > related.
>     >
>     > Thank you very much,