From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50 invoked by alias); 11 Sep 2015 17:35:43 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 36489 Received: (qmail 12604 invoked from network); 11 Sep 2015 17:35:42 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AC_DIV_BONANZA,BAYES_00, FREEMAIL_FROM,HTML_MESSAGE,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=KWg6HzTjf6fxTBFUA7T6h0DrcRJlbIBmV8GkUrGGt0M=; b=WcZacVc6xtlyCofE59SUelaR7jzUz6GVrKUUDZtAJGvWiDUk1tQRYWwHHD73VxU2vs IsE7GQi9vDK8jCbZOvGM9amUUzpwt2fsSBvv1P5Rqd3XKoJkj6oQtlCLiUFCy2jw2plD Vw7T+gvFgv3aHHQIU/XY3ynvUUKZELDkjpf0XriOtSDfoY1CXeg2Om/+lWh0OT0cdsMJ qgITyumui+KfJ3tVle8c1grwaTdFLeyRuEFrN+JtXw4F8z+HMCWwQpUBhls/FivFaVuy MqNEGn0GSvdCYx3YNNJY3C3fVgF9IBeEENRvP9CSGUrF8SN2mzO5xjISjSgqeJqi7qVU 3qCw== X-Received: by 10.112.160.73 with SMTP id xi9mr42407619lbb.92.1441992937563; Fri, 11 Sep 2015 10:35:37 -0700 (PDT) MIME-Version: 1.0 From: Sebastian Gniazdowski Date: Fri, 11 Sep 2015 19:35:17 +0200 Message-ID: Subject: Patch for curses module To: zsh-workers@zsh.org Content-Type: multipart/mixed; boundary=001a11c235f6d034f3051f7c245b --001a11c235f6d034f3051f7c245b Content-Type: multipart/alternative; boundary=001a11c235f6d034ea051f7c2459 --001a11c235f6d034ea051f7c2459 Content-Type: text/plain; charset=UTF-8 Hello, while working on Zsh Navigation Tools I encountered random changing, blinking of colors (in n-options). This not always reproduced, but luckily on one FreeBSD box it did always reproduce. After going into the code I established that following code in curses.c: if (zc_color_phase==1 || !(cpn = (Colorpairnode) gethashnode(zcurses_colorpairs, colorpair))) { should be: if (zc_color_phase==1 || !(cpn = (Colorpairnode) gethashnode2(zcurses_colorpairs, colorpair))) { The author defined the hash table with gethashnode2() from the beginning: zcurses_colorpairs->getnode = gethashnode2; zcurses_colorpairs->getnode2 = gethashnode2; However there he called the non-2 version. Result was as follows: - only first initialized color pair was found by the non-2 gethashnode() function, in my case white/black - each call to set a color pair (zcurses attr) other than the white/black caused a miss in hash table, and creation of new entry - I easily obtained number of color pairs like 300 when actually using only three colors (color pairs) It seems that gethashnode() can return first hash table entry, but not others, when called on a hash table like the author's. I wonder what can be done to be able to use colors without memory leaks or at least without occasional blinking on zsh <= 5.1. It's not good that so many zsh's are affected by the bug, making colors in zcurses problematic in near future if user doesn't obtain a very fresh version. Best regards, Sebastian Gniazdowski --001a11c235f6d034ea051f7c2459 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
while working on Zsh Navigation Tools I encountered rando= m changing, blinking of colors (in n-options). This not always reproduced, = but luckily on one FreeBSD box it did always reproduce.

After = going into the code I established that following code in curses.c:

= =C2=A0=C2=A0=C2=A0 if (zc_color_phase=3D=3D1 ||
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 !(cpn =3D (Colorpairnode) gethashnode(zcurses_colorpairs= , colorpair))) {

should be:

=C2=A0=C2=A0=C2=A0 if (zc_c= olor_phase=3D=3D1 ||
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 !(cpn = =3D (Colorpairnode) gethashnode2(zcurses_colorpairs, colorpair))) {

=
The author defined the hash table with gethashnode2() from the beginn= ing:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 zcurses_colorpairs->getnode=C2=A0=C2=A0=C2=A0=C2=A0 =3D gethashnode2= ;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 zcu= rses_colorpairs->getnode2=C2=A0=C2=A0=C2=A0 =3D gethashnode2;

However there he called the non-2 version.

Result was as fo= llows:
- only first initialized color pair was found by the non-2 = gethashnode() function, in my case white/black
- each call to set = a color pair (zcurses attr) other than the white/black caused a miss in has= h table, and creation of new entry
- I easily obtained number of c= olor pairs like 300 when actually using only three colors (color pairs)
=
It seems that gethashnode() can return first hash table entry, bu= t not others, when called on a hash table like the author's.

I wonder what can be done to be able to use colors without memory l= eaks or at least without occasional blinking on zsh <=3D 5.1. It's n= ot good that so many zsh's are affected by the bug, making colors in zc= urses problematic in near future if user doesn't obtain a very fresh ve= rsion.

Best regards,
Sebastian Gniazdowski=

--001a11c235f6d034ea051f7c2459-- --001a11c235f6d034f3051f7c245b Content-Type: application/octet-stream; name="curses.patch" Content-Disposition: attachment; filename="curses.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iefwqhf60 ZGlmZiAtLWdpdCBhL1NyYy9Nb2R1bGVzL2N1cnNlcy5jIGIvU3JjL01vZHVsZXMvY3Vyc2VzLmMK aW5kZXggNjJkYmQ1NS4uMDA1NGFlZiAxMDA2NDQKLS0tIGEvU3JjL01vZHVsZXMvY3Vyc2VzLmMK KysrIGIvU3JjL01vZHVsZXMvY3Vyc2VzLmMKQEAgLTMzOSw3ICszMzksNyBAQCB6Y3Vyc2VzX2Nv bG9yZ2V0KGNvbnN0IGNoYXIgKm5hbSwgY2hhciAqY29sb3JwYWlyKQogCXJldHVybiBOVUxMOwog CiAgICAgaWYgKHpjX2NvbG9yX3BoYXNlPT0xIHx8Ci0JIShjcG4gPSAoQ29sb3JwYWlybm9kZSkg Z2V0aGFzaG5vZGUoemN1cnNlc19jb2xvcnBhaXJzLCBjb2xvcnBhaXIpKSkgeworCSEoY3BuID0g KENvbG9ycGFpcm5vZGUpIGdldGhhc2hub2RlMih6Y3Vyc2VzX2NvbG9ycGFpcnMsIGNvbG9ycGFp cikpKSB7CiAJemNfY29sb3JfcGhhc2UgPSAyOwogCWNwID0genRyZHVwKGNvbG9ycGFpcik7CiAK --001a11c235f6d034f3051f7c245b--