NetBSD Problem Report #56388

From www@netbsd.org  Sat Sep  4 13:05:05 2021
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id EF74D1A923A
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  4 Sep 2021 13:05:04 +0000 (UTC)
Message-Id: <20210904130503.48C7F1A923B@mollari.NetBSD.org>
Date: Sat,  4 Sep 2021 13:05:03 +0000 (UTC)
From: rokuyama.rk@gmail.com
Reply-To: rokuyama.rk@gmail.com
To: gnats-bugs@NetBSD.org
Subject: curses addstr test fails for LP64BE platforms
X-Send-Pr-Version: www-1.0

>Number:         56388
>Category:       lib
>Synopsis:       curses addstr test fails for LP64BE platforms
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 04 13:10:00 +0000 2021
>Closed-Date:    Sun Sep 19 04:36:41 +0000 2021
>Last-Modified:  Sun Sep 19 04:36:41 +0000 2021
>Originator:     Rin Okuyama
>Release:        9.99.88
>Organization:
Department of Physics, Meiji University
>Environment:
NetBSD rp64 9.99.88 NetBSD 9.99.88 (GENERIC64EB) #308: Sat Sep  4 19:19:46 JST 2021  rin@latipes:/sys/arch/evbarm/compile/GENERIC64EB evbarm aarch64eb
>Description:
tests/lib/libcurses/t_curses:addstr fails when comparing output with
check_files/addstr2.chk on aarch64eb. By enabling -v flag to director,
I obtain:

---
tc-se:director: /usr/tests/lib/libcurses/tests/addstr:19: [do_function_call] Excess 172 bytes from slave [cup24;1X0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456cup24;1Xclearcsr1;24Xhomecup24;1Xindn4Xcsr1;24Xhomehomecup24;76Xa\040\040\040rmamhsmamcup24;1X]
tc-se:Comparing reference byte 0x63 (c) against slave byte 0x63 (c)
...
tc-se:Comparing reference byte 0x75 (u) against slave byte 0x73 (s)
---

On the other hand, addstr2.chk reads:

----
cup24;1X0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456cup24;1Xclearcup24;76Xa   rmamhsmamcup24;1X
----

So, ``csr1;'' is output where ``cup24;'' is expected.

This test also fails for sparc64:

https://releng.netbsd.org/b5reports/sparc64/2021/2021.09.03.12.20.38/test.tps

whereas it passes other platforms including ILP32BE ones. So, I guess
that this is an LP64BE bug in libcurses.
>How-To-Repeat:
On LP64BE machines:

cd /usr/tests/lib/libcurses && atf-run
>Fix:
N/A

>Release-Note:

>Audit-Trail:
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: "gnats-bugs@NetBSD.org" <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: lib/56388: curses addstr test fails for LP64BE platforms
Date: Tue, 7 Sep 2021 01:07:39 +0900

 Oops, not sent to gnats-bugs@...

 -------- Forwarded Message --------
 Subject: Re: lib/56388: curses addstr test fails for LP64BE platforms
 Date: Mon, 6 Sep 2021 21:25:28 +0900
 From: Rin Okuyama <rokuyama.rk@gmail.com>
 Reply-To: gnats-bugs@netbsd.org
 To: lib-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
 CC: Brett Lymn <blymn@internode.on.net>

 In __newwin() and __resizewin(), hash value for line is calculated
 as if HAVE_WCHAR is disabled.

 If this bug is fixed with this patch:

 https://gist.github.com/rokuyama/fad462d0b63934e909b83b584dd3cdc6

 addstr test becomes to fail on other platforms including amd64, in
 the same manner as on LP64BE machines.

 On the other hand, even if this patch is applied, the test case for
 lib/55931 (for which this part of test was introduced) does not fail;
 the overflown text is truncated instead of overwrapped.

 Also, I've confirmed that there is no regression in other ATF tests.

 So, I think that check_files/addstr2.chk is generated depending on
 ``wrong'' behavior due to the bug, and should be regenerated after
 the bug is fixed.

 Thoughts?

 Thanks,
 rin

From: Brett Lymn <blymn@internode.on.net>
To: gnats-bugs@netbsd.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: lib/56388: curses addstr test fails for LP64BE platforms
Date: Tue, 7 Sep 2021 07:43:55 +0930

 On Mon, Sep 06, 2021 at 09:25:28PM +0900, Rin Okuyama wrote:
 > 
 > So, I think that check_files/addstr2.chk is generated depending on
 > ``wrong'' behavior due to the bug, and should be regenerated after
 > the bug is fixed.
 > 
 > Thoughts?
 > 

 Yes, the check file should be regenerated.  Initially when writing the
 tests I was manually generating the check files but this takes too much
 time and is hard to maintain so now current behaviour is captured -
 wrong or right.  So, yes, if the behaviour changes when a bug is fixed
 then the check needs to be regenerated as long as the impacts on other
 tests (if any) are considered.

 -- 
 Brett Lymn
 --
 Sent from my NetBSD device.

 "We are were wolves",
 "You mean werewolves?",
 "No we were wolves, now we are something else entirely",
 "Oh"

From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56388 CVS commit: src/lib/libcurses
Date: Tue, 7 Sep 2021 01:23:10 +0000

 Module Name:	src
 Committed By:	rin
 Date:		Tue Sep  7 01:23:10 UTC 2021

 Modified Files:
 	src/lib/libcurses: cur_hash.c curses_private.h newwin.c refresh.c
 	    resize.c

 Log Message:
 PR lib/56388

 For __newwin() and __resizewin(), the line hash was calculated as if
 HAVE_WCHAR is disabled.

 Fix this bug by refactoring __hash_line() function, which calculates
 the line hash by an appropriate method.


 To generate a diff of this commit:
 cvs rdiff -u -r1.13 -r1.14 src/lib/libcurses/cur_hash.c
 cvs rdiff -u -r1.75 -r1.76 src/lib/libcurses/curses_private.h
 cvs rdiff -u -r1.61 -r1.62 src/lib/libcurses/newwin.c
 cvs rdiff -u -r1.115 -r1.116 src/lib/libcurses/refresh.c
 cvs rdiff -u -r1.32 -r1.33 src/lib/libcurses/resize.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56388 CVS commit: src/tests/lib/libcurses/check_files
Date: Tue, 7 Sep 2021 01:29:13 +0000

 Module Name:	src
 Committed By:	rin
 Date:		Tue Sep  7 01:29:13 UTC 2021

 Modified Files:
 	src/tests/lib/libcurses/check_files: addstr2.chk

 Log Message:
 PR lib/56388

 Regen addstr2.chk after fix for the line-hash bug in libcurses.

 Now, all t_curses tests successfully pass on all platforms I have tried.

 Thanks blymn@ for kind advice!


 To generate a diff of this commit:
 cvs rdiff -u -r1.2 -r1.3 src/tests/lib/libcurses/check_files/addstr2.chk

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Rin Okuyama <rokuyama.rk@gmail.com>
To: Brett Lymn <blymn@internode.on.net>,
 "gnats-bugs@NetBSD.org" <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: lib/56388: curses addstr test fails for LP64BE platforms
Date: Tue, 7 Sep 2021 10:33:51 +0900

 On 2021/09/07 7:13, Brett Lymn wrote:
 > On Mon, Sep 06, 2021 at 09:25:28PM +0900, Rin Okuyama wrote:
 >>
 >> So, I think that check_files/addstr2.chk is generated depending on
 >> ``wrong'' behavior due to the bug, and should be regenerated after
 >> the bug is fixed.
 >>
 >> Thoughts?
 >>
 > 
 > Yes, the check file should be regenerated.  Initially when writing the
 > tests I was manually generating the check files but this takes too much
 > time and is hard to maintain so now current behaviour is captured -
 > wrong or right.  So, yes, if the behaviour changes when a bug is fixed
 > then the check needs to be regenerated as long as the impacts on other
 > tests (if any) are considered.
 > 

 Committed. As far as I can see, the change does not hurt other tests.
 Thank you so much for the useful comments!

 rin

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 19 Sep 2021 04:12:56 +0000
State-Changed-Why:
Is this fixed?


State-Changed-From-To: feedback->closed
State-Changed-By: rin@NetBSD.org
State-Changed-When: Sun, 19 Sep 2021 04:36:41 +0000
State-Changed-Why:
Fixed. Official test runs for sparc64 got fixed, too:
https://releng.netbsd.org/b5reports/sparc64/commits-2021.09.html#2021.09.07.13.29.41


>Unformatted:

Home	PR Database Search