Bug 1417355 - tigervnc crashes against zlib-1.2.7+
Summary: tigervnc crashes against zlib-1.2.7+
Alias: None
Product: Fedora
Classification: Fedora
Component: zlib
Version: rawhide
Hardware: Unspecified
OS: Linux
Target Milestone: ---
Assignee: Pavel Raiskup
QA Contact: Fedora Extras Quality Assurance
Depends On: 844791
TreeView+ depends on / blocked
Reported: 2017-01-28 05:46 UTC by Pavel Raiskup
Modified: 2017-02-05 11:57 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 844791
: 1417855 (view as bug list)
Last Closed: 2017-02-05 11:57:03 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 151080 0 None None None 2017-01-30 08:11:34 UTC

Description Pavel Raiskup 2017-01-28 05:46:06 UTC
Patch zlib-1.2.7-z-block-flush.patch was added because tigervnc server
crashed with zlib 1.2.7.  It was deducted that zlib's upstream commit
f1ebdd6a9c495a5db9a22aa80dd7d54ae7db42e9 triggered this failure.

First of all, I don't see how f1ebdd6a9c4 commit can be wrong ... and so
partly reverting the patch (by re-ranking Z_BLOCK flush to stronger flush)
does not make sense to me.  This patch seems to bring a bug in API.

Then, we seem to have no reproducer for this issue, and after a lot of
trying I'm not able to reproduce this with Fedora's tigervnc against old
(without block-flush.patch) zlib.  Perhaps this has been fixed in tigervnc
at the end?  I was also trying to bulid old tigervnc, but it turns out to be a
non-trivial task (tiger vnc brings some xserver versoin-specific set of
patches, and unfortunately the old tigervnc 1.1.0 doesn't have a patch
for quite new xserver 1.17 (which is now in RHEL 7).

Because the downstream patch in zlib seems to be wrong, and looks like it
is not needed for tigervnc now -- I'll give it a few days (waiting for any
response) and then (when no objections) I'll revert the patch.

Any help here would be really appreciated.

Comment 1 Pavel Raiskup 2017-01-30 08:42:18 UTC
Ok, I can confirm that drop of this patch is fairly safe, because upstream
of tigervnc applied b5822f32ab5043b4e70e55ccbac0f548a2f784fc commit to fix
(work-around zlib) issue.  Reverting this patch in EPEL7 leads to
tigervnc-server failure (similarly on Fedora) with reproducer:

  server $ vncserver # starts on :2
  client $ vncviewer CompressLevel=2 server:2

with the following server log:

  Xvnc TigerVNC 1.3.1 - built Jan 29 2017 15:56:11 Copyright (C) 1999-2011
  TigerVNC Team and many others (see README.txt) See
  http://www.tigervnc.org for information on TigerVNC.  Underlying X
  server release 11702000, The X.Org Foundation

  Mon Jan 30 09:29:43 2017
   vncext:      VNC extension running!
   vncext:      Listening for VNC connections on all interface(s), port
   vncext:      created VNC server for screen 0

  Mon Jan 30 09:30:00 2017
   Connections: accepted:
   SConnection: Client needs protocol version 3.8
   SConnection: Client requests security type VeNCrypt(19)

  Mon Jan 30 09:30:02 2017
   VNCSConnST:  Server default pixel format depth 24 (32bpp) little-endian
   rgb888 VNCSConnST:  Client pixel format depth 24 (32bpp) little-endian
   rgb888 Connections: closed: (ZlibOutStream:
   deflateParams failed) SMsgWriter:  framebuffer updates 1

Comment 2 Pavel Raiskup 2017-02-05 11:57:03 UTC
Fixed in Rawdhide (F26) by:

Note You need to log in before you can comment on or make changes to this bug.