ked@garnet.berkeley.edu (Earl H. Kinmonth) (04/13/89)
In the course of recovering from damage to my XENIX partition caused by Norton under MSDOS (the fixed version still can screw up XENIX), I reinstalled XENIX. After I did so, the first time I ran spell, I got the results below table = malloc(0xc848) fails sbrk(0) = 0x3868 spell: cannot initialize hash table spell: 5791 Killed Several hours of diddling revealed that this did NOT occur when I ran spell as root. Thinking this might be a setuid problem, I ran fixperm. No luck. I then tried playing with the permissions by hand. No luck. I finally remembered what I had done the first time I had installed 80286 SCO Xenix and encountered this problem. I dug out my 8086 Xenix and installed the spellprog and related files from it. This cured the problem. Is there a more "elegant" solution?
rosso@sco.COM (Ross Oliver) (04/21/89)
In article <23002@agate.BERKELEY.EDU> ked@garnet.berkeley.edu (Earl H. Kinmonth) writes: >In the course of recovering from damage to my XENIX partition caused >by Norton under MSDOS (the fixed version still can screw up XENIX), I >reinstalled XENIX. After I did so, the first time I ran spell, I got >the results below > >table = malloc(0xc848) fails >sbrk(0) = 0x3868 >spell: cannot initialize hash table >spell: 5791 Killed This means that spell has run out of data space. Spell is small model program, so it is limited ot 64K of data. This problem usually occurs when you have a lot of environment data (i.e. lots of environment variables, and/or variables containing lots of data), which also explains why it will happen to one user, but not another. The quickest way to check this is to change your TERM environment variable from containing your entire termcap entry (usually several lines long) to be "/etc/termcap." This should free up enough space for spell to work. Ross Oliver Technical Support The Santa Cruz Operation, Inc.
daveh@marob.MASA.COM (Dave Hammond) (04/25/89)
In article <2572@viscous.sco.COM> uunet!sco!rosso (Ross Oliver) writes: >[... spell has run out of data space. ...] The quickest >way to check this is to change your TERM environment variable from >containing your entire termcap entry (usually several lines long) to >be "/etc/termcap." [...] Ross means TERMCAP, not TERM. It's usually sufficient to just `unset TERMCAP', since the termcap library routines will default to /etc/termcap. This trick also helps if you try to run a shell script under `ksh' which contains lots of function definitions, and get `no memory' (try running /etc/custom under ksh). -- Dave Hammond daveh@marob.masa.com