filePro 32-bit binaries segv on CentOS 64-bit

[Fairlight]

On Tue, Feb 18, 2014 at 04:42:36PM -0500, Kenneth Brody thus spoke:
>
> filePro gives a "terminal type not found" error, and has done so since
> 1.0 was released.
>
[snip]
>
> Well, with dclerk 5.0.15D4 (the oldest Linux version I know where to
> find), I get:
>
>    *** a filePro Error Has Occurred ***
>
>    On File: /appl/fp/lib/config
>
>    Terminal type not found.  Alert your system administrator.  Press H
>    -Hardcopy Return -Continue

Okay, my initial conclusino wasn't 100% correct.  Close, but not -quite-.
I did, however, narrow it down to what causes it to bail.  It's still
termcap, just not how I originally thought.

The screen(1) program puts an entire termcap entry into $TERMCAP in the
environment.  If one runs screen and unsets $TERMCAP, no segv and it seems
to perform as expected.  If one leaves the entry below in the environment
variable, definite and immediate segv.

Oh, I should mention that it happens on both 32-bit and 64-bit.  It has
zero to do with the bit size of the platform.  The reason I saw it on
64-bit was because that version of screen is injecting a TERMCAP variable
into the environment, while the version of screen on the 32-bit platform is
not doing so.  It's only 4.0.3 vs 4.0.2, and I remember screen injecting
TERMCAP into the environment for years before the latest versions, so I
would think it's somewhere in the screenrc, or in how it's compiled.  Not
sure, and I don't have the time to waste figuring it out.  The offending
environment variable:

TERMCAP=SC|screen.linux|VT 100/ANSI X3.64 virtual terminal:\
        :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\
        :cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\
        :do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\
        :le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\
        :li#25:co#80:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\
        :cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\
        :im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\
        :ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\
        :ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E[24m:so=\E[3m:\
        :se=\E[23m:mb=\E[5m:md=\E[1m:mh=\E[2m:mr=\E[7m:\
        :me=\E[m:ms:\
        :Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\
        :vb=\Eg:as=\E(0:ae=\E(B:\
        :ac=\140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\
        :k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:\
        :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:\
        :F1=\E[23~:F2=\E[24~:F3=\E[25~:F4=\E[26~:F5=\E[28~:\
        :F6=\E[29~:F7=\E[31~:F8=\E[32~:F9=\E[33~:FA=\E[34~:kb=^?:\
        :K2=\E[G:kB=\E[Z:kh=\E[1~:@1=\E[1~:kH=\E[4~:@7=\E[4~:\
        :kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:\
        :kr=\EOC:kl=\EOD:

And no, I'm not going to figure out the exact part of that which causes it
to bail.  :)  I just know it will definitely cause all filePro binaries to
immediately segv on startup.  You want to figure it out, install CentOS 6,
install screen, run screen, then run dclerk.  It's not like I had to go out
of my way to run into it.  I'd wager RHEL 6 is equally susceptible,
considering CentOS is a downstream redist of RH.

There's still no way it should segv simply because an environment variable
is set for TERMCAP.  I tried for a backtrace, but couldn't get one out of
gdb because not all the 32-bit libraries have debuginfo packages.

(gdb) run
Starting program: /home/appl/fp_v5.0.14D4/dclerk

Program received signal SIGSEGV, Segmentation fault.
0xf7e88c5f in __strlen_ia32 () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install
compat-libtermcap-2.0.8-49.el6.i686 glibc-2.12-1.132.el6.i686
(gdb) bt
#0  0xf7e88c5f in __strlen_ia32 () from /lib/libc.so.6
#1  0xf7e534df in vfprintf () from /lib/libc.so.6
#2  0xf7e7296c in vsprintf () from /lib/libc.so.6
#3  0xf7e5a52b in sprintf () from /lib/libc.so.6
#4  0x080ad11d in ?? ()
#5  0x080ad2bb in ?? ()
#6  0x434f455c in ?? ()
#7  0x3d6c6b3a in ?? ()
#8  0x444f455c in ?? ()
#9  0x0000003a in ?? ()
#10 0x080fb099 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

Unfortunately, debuginfo-install from yum-utils has no available packages
for those libraries, no matter what gdb thinks.  And that's as far as I can
go on a backtrace without symbols.

mark->
-- 
Fairlight Consulting
http://www.fairlite.com
fairlite at fairlite.com
(502) 509-3840