Bug 70680 - Terminal Emulation issues in AS2.1 (d413-unix)
Terminal Emulation issues in AS2.1 (d413-unix)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: libtermcap (Show other bugs)
2.1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Raszyk
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-03 17:58 EDT by Steve Taylor
Modified: 2015-01-07 18:58 EST (History)
1 user (show)

See Also:
Fixed In Version: libtermcap-2.0.8 Release 44
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-13 02:02:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
libtermcap-2.0.8-44.src.rpm (223.16 KB, application/x-rpm)
2006-01-13 09:06 EST, Petr Raszyk
no flags Details

  None (edit)
Description Steve Taylor 2002-08-03 17:58:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513

Description of problem:
I am setting up an annex with dumb terminals using a  d413-unix emulation and
also Kermit-95 using a D217 emulation from my W2k box.  These are Date General
terminal emulations.  Both of these emulations exist in the termcap and terminfo
files.

The problem is that when I attempt to login using these emulations it
immediately disconnects me.  If I login with an "unknown" TERM then it lets me
in but as soon as I set the TERM it disconnects me (TERM=d413-unix ; export
TERM).  Below are two examples with the term set right (in these cases, I never
get a shell prompt when trying to connect).

If I am in BASH, I get a crash and then disconnected:
login:
Password:
Last login <snip>
malloc: block on free list clobbered
last command: TERM=d413-unix;export TERM
Stopping Myself...
   telnet <snip> closed

If I am in TCSH, I get an error and then disconnected:
login:
Password:
Last login <snip>
root: Command not found.
root: Undefined variable
telnet <snip> closed

Because both shells do it, I suspect it isn't the shell but something else.  I'm
not really sure where to search for help on this one... I dug into google groups
and found one reference to a bug in RedHat back in 6.x (18 months ago), but
nothing since then.

http://groups.google.com/groups?hl=en&lr=&ieUTF-
&&am&&threadm=1010201152859.AA87584.SM@nike.INS.CWRU.Edu&rnum=4&prev=/groups?q%
3Dtermcap+%22stopping+myself%22&hl=en&lr=&ie=UTF-8&selm%
3D1010201152859.AA87584.SM%40nike.INS.CWRU.Edu&rnum=4

Any ideas? I have worked with Termcap files on DG Unix, but never ran into a
disconnect like this.

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


How reproducible:
Always

Steps to Reproduce:
1.Login with unknown TERM
2.TERM=d413-unix ; export TERM

	

Actual Results:  Crashed session

Expected Results:  Term type set properly

Additional info:

Bug in our termcap rather...

The d413-unix termcap type ends up as a modified d216e+ terminal type. If you
read the termcap entry for it, the last line looks like:

        :sf=^J:ta=^I:up=^^PA:tc=dgkeys+15:tc=d216-dg:

The last two bits of these are the interesting ones:

    tc=dgkeys+15
    tc=d216-dg

You can't use tc= twice in a single termcap entry. This probably shouldn't segv
our binary (and I now hope that we don't have any setuid apps that use termcap;
a brief check didn't find anything but someone should check for sure). 

Anyway, if you remove the "tc=dgkeys+15" bit, this problem goes away. Put this
in bugzilla and please include my commentary. In the meantime, you can tell the
customer to change that last line to:

        :sf=^J:ta=^I:up=^^PA:tc=d216-dg:

and he should be all set.

Erik
Comment 1 Petr Raszyk 2006-01-13 09:06:48 EST
Created attachment 123163 [details]
libtermcap-2.0.8-44.src.rpm

Many thanks for your examples !
'termcap' seems to be OK (you can use tc=  twice).
The bug was in libtermcap.
Fixed in devel (CURRENT RELEASE).
Tested in i386, x86_64, ... (using libtermcap-2.0.8-44 in your scenario).

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