Xref: utzoo comp.unix.sysv386:9256 biz.sco.general:332 comp.unix.xenix.sco:2851
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!ucsd!mvb.saic.com!ncr-sd!crash!bblue
From: bblue@crash.cts.com (Bill Blue)
Newsgroups: comp.unix.sysv386,biz.sco.general,comp.unix.xenix.sco
Subject: Re: foxbase panics sco unix
Keywords: pack foxbase sco
Message-ID: <1991Jun23.075733.16944@crash.cts.com>
Date: 23 Jun 91 07:57:33 GMT
References: <1991Jun22.183814.1673@scuzzy.in-berlin.de>
Organization: Crash TimeSharing, El Cajon, CA
Lines: 39

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.

Note that just prior to the initial kernel messages, there's a bunch
of additional back-and-forth disk activity between the hd with swap on
it, and the hd with the foxplus files.  There shouldn't be any
swapping at all, and vmstat says there isn't.  I've tried it on three
different machines, differently configured all with 8-12mb ram and
always >7mb swap space.

Older versions of Foxplus did not exhibit this behavior on any size
file.

Regular cp copies of the files are fine, of course.  Problem only
shows up in Foxplus.

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...

--Bill