filePro 32-bit binaries segv on CentOS 64-bit

Fairlight fairlite at fairlite.com
Tue Feb 18 12:59:18 PST 2014


On Tue, Feb 18, 2014 at 01:43:43PM -0500, Kenneth Brody thus spoke:
> 
> I think I saw a similar crash when someone else had decided to
> simply copy the 64-bit libs into the 32-bit library directory.

Seriously?  You're not even going to credit me with more brains than to do
that, when I've been in the linux game for -how- long?  (Hint:  This year
makes two decades.)

> If you run "ldd dclerk", and then use "file" on each of the listed
> paths, do they all show as "32-bit"?

They're all 32-bit versions, yes.  It was/is a fresh install, and I was the
only person involved, so nothing boneheaded was done.

I've isolated the problem, no thanks to filePro's lack of fault tolerance.

Since the "network engineer" has continuously and steadfastly refused to
nuke the 10min idle timeout at the firewall level, and it's quite often
necessary to flip screens, do research, hunt things down, take a whiz,
etc., my workaround has been to use screen(1) for its autodetach feature
while doing heavy administrative work on systems.  If I get idled out for
no input, despite being in the middle of a -massive- rsync or other task,
no harm, no foul, I just reconnect when I flip back, and no progress lost.
And I don't even usually have to think about being in that environment,
because everything else I deal with is sane about working under it.

Well...  It appears that none of the filePro binaries actually check to
see if a termcap entry exists for $TERM, and I had no PFTERM set (which is
arguably optional, and certainly not enforeed by way of any error/warning
messages).

So instead of doing the logical thing and telling you that no
'screen.linux' termcap entry exists for filePro, it just up and segfaults
with no explanation.  And strace() is of zero help in diagnosing the actual
cause of the segv.

LOVELY fault tolerance and data bounds checking.  Not.

5.0.14D4

I can only blame the network engineer so far for having to use the
environment I do.  This is really an inexcusably missing data bounds/fault
tolerance check that leads to a merry goose chase.

mark->
-- 
Audio panton, cogito singularis.


More information about the Filepro-list mailing list