Xref: utzoo comp.unix.sysv386:9302 biz.sco.general:342 comp.unix.xenix.sco:2875
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!ahmcs!alan
From: alan@ahmcs.uucp (Alan Mintz)
Newsgroups: comp.unix.sysv386,biz.sco.general,comp.unix.xenix.sco
Subject: Re: foxbase panics sco unix
Summary: Sounds familiar
Keywords: pack foxbase sco
Message-ID: <218@ahmcs.uucp>
Date: 25 Jun 91 02:00:48 GMT
References: <1991Jun22.183814.1673@scuzzy.in-berlin.de> <1991Jun23.075733.16944@crash.cts.com>
Followup-To: comp.unix.sysv386
Organization: Micro-Quick Systems, Inc.
Lines: 47

In article <1991Jun23.075733.16944@crash.cts.com>, bblue@crash.cts.com (Bill Blue) writes:
) In <1991Jun22.183814.1673@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes:
) }i have a problem with SCO FoxBase 2.1 running under SCO UNIX 2.0GT:
) }while reindexing the databases (biggest ~10MB) with 'pack' the
) }machine panics with 'trying to free already freed block'.
) }now i thought this is the bug that causes invalid inode table entries
) }that should be fixed by unx279, but that didn't help. i even reinstalled
) }from scratch to be sure to apply the patch to a clean kernel, but
) }the panic persist. i should note that it doesn't always panic, but
) }you can sure wait for it, reindexing 2 or 3 times does it.
) }
) }any pointers?
) 
) Not exactly, but I have seen a similar behavior with Foxplus 2.1.2 on
) SCO Xenix (2.3.3).  Seems that if you pack, or copy, or do any
) operation that results in Foxplus doing a copy, on a file much larger
) than 1mb, you get a string of kernel: out of swap messages to the
) screen.  If it's a file of borderline size (borderline to the problem)
) you might get by with the operation completed successfully, even with
) the error messages.  But if the file is too large and you let it go,
) it will ultimately always panic and bring the system down.

Hmmm. I have customers using SCO Foxbase+ 2.1.1 and 2.1.2 routinely operate
on files as big as 30 Mb without problems under SCO XENIX 2.3.2AT. 2.3.2GT,
2.3.4GT, and SCO UNIX 3.2v2.0. 

I do, however, recall a bug that cropped up in either 2.1.1 or 2.1.2, in which
altering the filtered field during a browse on a database with a filtered index
would cause the Fox+ process to runaway, consuming all memory and all swap.
As I think about it, I think this was in 2.1.1 because I remember a change in
the way browse "feels" under 2.1.2. Perhaps this is related.

Our typical kernel has NFILES and NINODES set to about 600, NPROC set to about
200, a Wangtek tape driver, and a Specialix serial driver. The UNIX boxes have
SCO TCP/IP 1.1.1 and 1.1.3.

) I'm hoping there's a newer version of the program that fixes this
) problem, as it certainly makes maintenance of large database files
) rather difficult...

Let SCO know. Foxbase+ has fallen pretty low on the resource priority list
in the last month. They have stated that there will not be another Fox+ release,
but I am starting to worry that the promised bug-fix SLS will not happen either.
-- 
< Alan H. Mintz  | alan@ahmcs.mq.com | ...!uunet!ahmcs!alan >