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:
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:
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 <dcomman...@users.sourceforge.net>
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
> 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
>
> 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,
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> VirtualGL-Users mailing list
> VirtualGL-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users
