src@scuzzy.in-berlin.de (Heiko Blume) (06/23/91)
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?
--
Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!]
public UNIX source archive [HST V.42bis]:
scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
uucp scuzzy!/src/README /your/homebblue@crash.cts.com (Bill Blue) (06/23/91)
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
alan@ahmcs.uucp (Alan Mintz) (06/25/91)
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 >
src@scuzzy.in-berlin.de (Heiko Blume) (06/28/91)
alan@ahmcs.uucp (Alan Mintz) writes: >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 is SCO crazy? what the hell do they think are the most (pc) database applications written in? if they want users to go from dos to unix they'd better keep fox going! -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!] public UNIX source archive [HST 14400 V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
timr@sco.COM (Tim Ruckle) (06/28/91)
In article <218@ahmcs.uucp> alan@ahmcs.uucp (Alan Mintz) writes: } <...> } 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. The SLS will happen. Should be available in 3-6 months. I don't think anybody in-house has been able to replicate this bug--if there is any additional information that might help in doing so, mail it to me and I'll pass it on to engineering. -timr -- Usenet: !{uunet,ucbvax!ucscc,decvax!microsof}!sco!timr, ...!mcsun!ukc!scol!timr Internet: [MX handlers] timr@sco.COM [others] timr%sco.COM@ucscc.UCSC.EDU USPS: The Santa Cruz Operation, 400 Encinal Street, Santa Cruz, CA 95061-1900 PSDN: [voice] (408) 425-7222 [fax] (408) 458-4227 [twx] 910-598-4510 SCO SACZ