Bug 1417355

Summary:	tigervnc crashes against zlib-1.2.7+
Product:	[Fedora] Fedora	Reporter:	Pavel Raiskup <praiskup>
Component:	zlib	Assignee:	Pavel Raiskup <praiskup>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	atkac, bugproxy, dan, hannsj_uhl, jaromir.capik, jchaloup, jscotka, jstodola, kvolny, mbanas, ovasik, praiskup, pschiffe, rvokal, twaugh, wgomerin
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	844791
Clones:	1417855 (view as bug list)		Environment:
Last Closed:	2017-02-05 11:57:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	844791
Bug Blocks:

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
   5903
   vncext:      created VNC server for screen 0

  Mon Jan 30 09:30:00 2017
   Connections: accepted: 10.34.4.132::47716
   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: 10.34.4.132::47716 (ZlibOutStream:
   deflateParams failed) SMsgWriter:  framebuffer updates 1
  ...

Comment 2 Pavel Raiskup 2017-02-05 11:57:03 UTC

Fixed in Rawdhide (F26) by:
http://pkgs.fedoraproject.org/cgit/rpms/zlib.git/commit/?id=4871b1554bef470feb