From nobody@FreeBSD.ORG  Thu Sep 14 04:23:18 2000
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id EFE8037B43F; Thu, 14 Sep 2000 04:23:18 -0700 (PDT)
Message-Id: <20000914112318.EFE8037B43F@hub.freebsd.org>
Date: Thu, 14 Sep 2000 04:23:18 -0700 (PDT)
From: jacobsm@gate.net
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@FreeBSD.org
Subject: tn3270 port receives segmentation fault
X-Send-Pr-Version: www-1.0

>Number:         21264
>Category:       ports
>Synopsis:       tn3270 port receives segmentation fault
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    linimon
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Sep 14 04:30:02 PDT 2000
>Closed-Date:    Tue Feb 17 23:24:39 PST 2004
>Last-Modified:  Tue Feb 17 23:24:39 PST 2004
>Originator:     Mark Jacobs
>Release:        4.1 Stable
>Organization:
>Environment:
FreeBSD bc006429.tcs.timeinc.com 4.1-STABLE FreeBSD 4.1-STABLE #0:
Sun Sep 10 11:14:48 EDT 2000     root@bc006429.tcs.timeinc.com:
/usr/obj/usr/src/sys/MAIN  i386       
>Description:
Runing tn3270 port compiled on a 4.x system gives the following error

bash-2.04$ gdb tn3270
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain conditi
ons.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for detail
s.
This GDB was configured as "i386-unknown-freebsd"...
(no debugging symbols found)...
(gdb) run
Starting program: /usr/local/bin/tn3270
(no debugging symbols found)...(no debugging symbols found)...
tn3270> open ibmlink.advantis.com
Trying 204.146.168.209...
Connected to ibmlink.advantis.com.
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x2808ce88 in tgetent () from /usr/lib/libncurses.so.5
(gdb)   
>How-To-Repeat:
Compile tn3270 on 4.x Stable system, attempt to connect to 3270 system.
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-ports->markm 
Responsible-Changed-By: ade 
Responsible-Changed-When: Mon Sep 18 14:13:10 PDT 2000 
Responsible-Changed-Why:  
Over to maintainer 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21264 

From: Thomas David Rivers <rivers@dignus.com>
To: freebsd-gnats-submit@freebsd.org, freebsd-stable@freebsd.org,
	jacobsm@gate.net
Cc:  
Subject: Re: ports/21264: tn3270 port receives segmentation fault
Date: Tue, 19 Sep 2000 09:09:29 -0400 (EDT)

 Just investigating this further...
 
 There is a setupterm() function in the tn3270 sources (see line
 741 of telnet.c)  However, this is included only if  TERMCAP
 is defined.
 
 If you remove the TERMCAP definition from the CFLAGS in Makefile.inc, 
 tn3270 will "run" again.
 
 But, it is really ugly; each field is highlighted,  and the
 highlights seem to "hang around" (possibly an ncurses issue?)
 
 However, as to the particular bug - removing -DTERMCAP
 from the CFLAGs will fix it.
 
 Alternatively, renaming the setupterm() function
 in telnet.c also corrects the problem (again, giving
 the weird curses issues...)  For example,
 I simply renamed setupterm() to Setupterm() as
 in the following diff and things "worked" (this
 might be simpler to add as a patch):
 
 *** telnet.c.ori        Tue Sep 19 09:07:55 2000
 --- telnet.c    Tue Sep 19 09:07:47 2000
 ***************
 *** 738,744 ****
   
         /*ARGSUSED*/
         int
 ! setupterm(tname, fd, errp)
         char *tname;
         int fd, *errp;
   {
 --- 738,744 ----
   
         /*ARGSUSED*/
         int
 ! Setupterm(tname, fd, errp)
         char *tname;
         int fd, *errp;
   {
 ***************
 *** 772,778 ****
                 if (tnamep && tnamep != unknown)
                         free(tnamep);
                 if ((tname = (char *)env_getvalue((unsigned char *)"TERM")) &&
 !                               (setupterm(tname, 1, &err) == 0)) {
                         tnamep = mklist(termbuf, tname);
                 } else {
                         if (tname && (strlen(tname) <= 40)) {
 --- 772,778 ----
                 if (tnamep && tnamep != unknown)
                         free(tnamep);
                 if ((tname = (char *)env_getvalue((unsigned char *)"TERM")) &&
 !                               (Setupterm(tname, 1, &err) == 0)) {
                         tnamep = mklist(termbuf, tname);
                 } else {
                         if (tname && (strlen(tname) <= 40)) {
 
 
 
 
     - Dave Rivers -
 
 --
 rivers@dignus.com                         Work: (919) 676-0847
 Get your mainframe (370) `C' compiler at http://www.dignus.com
 

From: Mark.Jacobs@custserv.com
To: jacobsm@gate.net, freebsd-stable@freebsd.org,
	freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: ports/21264: tn3270 port rec
Date: Wed, 20 Sep 2000 13:35:00 -0400

 Just investigating this further...
 
 There is a setupterm() function in the tn3270 sources (see line
 741 of telnet.c)  However, this is included only if  TERMCAP
 is defined.
 
 If you remove the TERMCAP definition from the CFLAGS in Makefile.inc,
 tn3270 will "run" again.
 
 But, it is really ugly; each field is highlighted,  and the
 highlights seem to "hang around" (possibly an ncurses issue?)
 
 However, as to the particular bug - removing -DTERMCAP
 from the CFLAGs will fix it.
 
 Alternatively, renaming the setupterm() function
 in telnet.c also corrects the problem (again, giving
 the weird curses issues...)  For example,
 I simply renamed setupterm() to Setupterm() as
 in the following diff and things "worked" (this
 might be simpler to add as a patch):
 
 *** telnet.c.ori        Tue Sep 19 09:07:55 2000
 --- telnet.c    Tue Sep 19 09:07:47 2000
 ***************
 *** 738,744 ****
 
         /*ARGSUSED*/
         int
 ! setupterm(tname, fd, errp)
         char *tname;
         int fd, *errp;
   {
 --- 738,744 ----
 
         /*ARGSUSED*/
         int
 ! Setupterm(tname, fd, errp)
         char *tname;
         int fd, *errp;
   {
 ***************
 *** 772,778 ****
                 if (tnamep && tnamep != unknown)
                         free(tnamep);
                 if ((tname = (char *)env_getvalue((unsigned char *)"TERM")) &&
 !                               (setupterm(tname, 1, &err) == 0)) {
                         tnamep = mklist(termbuf, tname);
                 } else {
                         if (tname && (strlen(tname) <= 40)) {
 --- 772,778 ----
                 if (tnamep && tnamep != unknown)
                         free(tnamep);
                 if ((tname = (char *)env_getvalue((unsigned char *)"TERM")) &&
 !                               (Setupterm(tname, 1, &err) == 0)) {
                         tnamep = mklist(termbuf, tname);
                 } else {
                         if (tname && (strlen(tname) <= 40)) {
 
 
 
 
     - Dave Rivers -
 
 --
 rivers@dignus.com                         Work: (919) 676-0847
 Get your mainframe (370) `C' compiler at http://www.dignus.com
 
 
 To Unsubscribe: send mail to majordomo@FreeBSD.org
 with "unsubscribe freebsd-stable" in the body of the message
 

From: Steve Roome <steve@sse0691.bri.hp.com>
To: freebsd-gnats-submit@FreeBSD.org, jacobsm@gate.net
Cc: freebsd-ports@FreeBSD.org, imp@FreeBSD.org
Subject: ports/21264 : SOCKS5 port broken as well
Date: Wed, 27 Sep 2000 17:20:46 +0100

 Just thought I'd mention that the newest socks5 breaks due to this as
 well, same thing, seems to get into a nasty infinite loop between
 tgetent and setupterm like this snippet shows :
 
 #44 0x804efb3 in setupterm (tname=0x8073130 "xterm", fd=0, errp=0xbbc009f4) at ./telnet.c:606
 #45 0x280a8efe in tgetent () from /usr/lib/libncurses.so.5
 #46 0x804efb3 in setupterm (tname=0x8073130 "xterm", fd=0, errp=0xbbc00a64) at ./telnet.c:606
 #47 0x280a8efe in tgetent () from /usr/lib/libncurses.so.5
 
 There might be a patch that's relevant here, but it's not really very
 well documented, and I'm not in the mood to sit and try and work out
 what all these patches do right now.. =(
 
 ftp://dickey.his.com/ncurses/5.1/
 
 Just my $0.02
 
 	Steve
 

From: Warner Losh <imp@village.org>
To: Steve Roome <steve@sse0691.bri.hp.com>
Cc: freebsd-gnats-submit@FreeBSD.org, jacobsm@gate.net,
	freebsd-ports@FreeBSD.org
Subject: Re: ports/21264 : SOCKS5 port broken as well 
Date: Wed, 27 Sep 2000 12:09:51 -0600

 In message <20000927172046.D38818@moose.bri.hp.com> Steve Roome writes:
 : Just thought I'd mention that the newest socks5 breaks due to this as
 : well, same thing, seems to get into a nasty infinite loop between
 : tgetent and setupterm like this snippet shows :
 : 
 : #44 0x804efb3 in setupterm (tname=0x8073130 "xterm", fd=0, errp=0xbbc009f4) at ./telnet.c:606
 : #45 0x280a8efe in tgetent () from /usr/lib/libncurses.so.5
 : #46 0x804efb3 in setupterm (tname=0x8073130 "xterm", fd=0, errp=0xbbc00a64) at ./telnet.c:606
 : #47 0x280a8efe in tgetent () from /usr/lib/libncurses.so.5
 : 
 : There might be a patch that's relevant here, but it's not really very
 : well documented, and I'm not in the mood to sit and try and work out
 : what all these patches do right now.. =(
 : 
 : ftp://dickey.his.com/ncurses/5.1/
 
 Ideally I'd like to see us use the telnet, et al in the tree rather
 than the sockified telnet in this port.  Sadly, there's no easy way to
 create a port that depends on /usr/src :-(
 
 Warner
 
Responsible-Changed-From-To: markm->linimon 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Jan 8 14:29:36 PST 2004 
Responsible-Changed-Why:  
markm no longer maintains this port; I'll try to help the new 
maintainer to look after it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21264 
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Fri Feb 13 01:48:45 PST 2004 
State-Changed-Why:  
Is this still a problem with the port these days? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21264 
State-Changed-From-To: feedback->closed 
State-Changed-By: linimon 
State-Changed-When: Tue Feb 17 23:23:53 PST 2004 
State-Changed-Why:  
Submitter no longer uses this port.  I cannot duplicate the 
effect on 4.9.  If anyone using this port has a similar problem, 
please let me know. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21264 
>Unformatted:
