Bug 831366

Summary: ncurses caches the TERMINFO variable incorrectly
Product: [Fedora] Fedora Reporter: Philippe Troin <phil>
Component: ncursesAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: dickey, mlichvar
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-20 11:21:50 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
Test program
Patch curing the issue none

Description Philippe Troin 2012-06-12 17:17:07 EDT
Created attachment 591287 [details]
Test program

Description of problem:
Ncurses caches the TERMINFO variable incorrectly.
The problem manifests itself when processes change the TERMINFO while a curses session is ongoing.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. mkdir ~/terminfo
2. echo "someterm,use=xterm" > someterm
3. TERMINFO=~/terminfo tic someterm
4. Compile the attached test program:
    gcc -Wall -o cursestest cursestest.c -ltinfo
5. Run it:
    ./cursestest ~/terminfo

Actual results:
No/inherited TERMINFO
xterm 1
someterm 0
xterm 1
someterm 0

Expected results:
No/inherited TERMINFO
xterm 1
someterm 0
xterm 1
someterm 1
Comment 1 Philippe Troin 2012-06-12 17:20:19 EDT
Created attachment 591288 [details]
Patch curing the issue

This patch fixes the problem for ncurses-5.9-20120204.

Please note that the patch's first hunk fixes a memory allocation problem (the strings returned by getenv() are stored and then freed with free() which is a big no-no), while the second and third hunks actually fix the issue.

Comment 2 Thomas E. Dickey 2012-06-19 21:05:23 EDT
Odd - I've run this with valgrind many times without noticing the bug
(since the code is from October).  thanks
Comment 3 Philippe Troin 2012-06-20 11:35:15 EDT
The faulty code can only trigger if TERMINFO changes during the lifetime of a process, which is not very common.
I happen to do that in my login scripts, to change terminal features transparently (I hate the alternate screen used by vi/less/etc with a passion which I turn-off automagically be defining an alternate terminal derived from the current one), but that's unlikely to be common.

I've also noticed (and maybe I should open another bug for that) that the .spec does NOT clear TERMINFO before running and if you happen to have TERMINFO defined when running rpmbuild, the package build will fail as the install target will try to install terminal definitions in "$DESTDIR$TERMINFO".
You may want to clear (the new) TERMINFO_PATH (sp?) and friends as well.

Comment 4 Thomas E. Dickey 2012-06-27 07:57:54 EDT
I added this change on Friday (20120622).
Comment 5 Thomas E. Dickey 2012-06-27 08:07:09 EDT
For what it's worth, I wrap my package builds in a script that limits
the environment, leaving only TMPDIR, USER, PATH, HOME and LOGNAME.
I would assume that packagers do the same, more or less.
Comment 6 Fedora Update System 2012-10-15 13:26:15 EDT
ncurses-5.9-6.20121013.fc18 has been submitted as an update for Fedora 18.
Comment 7 Fedora Update System 2012-10-15 21:24:48 EDT
Package ncurses-5.9-6.20121013.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ncurses-5.9-6.20121013.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 8 Fedora Update System 2012-10-18 05:52:14 EDT
ncurses-5.9-7.20121017.fc18 has been submitted as an update for Fedora 18.
Comment 9 Fedora Update System 2012-12-20 11:21:55 EST
ncurses-5.9-6.20121013.fc18 has been pushed to the Fedora 18 obsolete repository.  If problems still persist, please make note of it in this bug report.