I have switched to TurboVNC and has not found any crashes yet. It's a great
viewer.  So it seems like TurboVNC session does not like my realVNC viewer.

My compute environment cannot easily build from source...I'm working on
that and if I"m lucky I can reproduce it with more debugging information.

Thanks!

On Thu, Mar 9, 2017 at 8:25 PM, DRC <dcomman...@users.sourceforge.net>
wrote:

> 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 <dcomman...@users.sourceforge.net
> > <mailto: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
> >     <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,
>
>
> ------------------------------------------------------------
> ------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> VirtualGL-Users mailing list
> VirtualGL-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users

Reply via email to