ho@helen.Berkeley.EDU (Kinson Ho) (06/14/91)
DYNIX bug with shmalloc (and possibly shbrk and shsbrk)
There is a bug with the DYNIX routines for allocating shared memory,
shmalloc, shbrk and shsbrk in DYNIX v3.0.17.10 for the Symmetry.
If there is insufficient disk space on the disk referenced by the shell
environment variable TMPPATH (or "." if TMPPATH is not set), a DYNIX
process calling shmalloc will be stuck in the "D" state, while the
disk ($TMPPATH) is filled at 100%.
Apparently an invisible file in created in $TMPPATH. "ls -al $TMPPATH"
will NOT show this file, but "df $TMPPATH" before and after the call
will show a difference.
Since there is no way to kill a process in "D" state, the only
solution is to reboot the machine. This is VERY VERY ANNOYING.
The people running the Symmetry here are not happy with this at all.
Is there an official patch for this bug? Why does the parallel
programming library need to create this huge file in $TMPPATH anyway?
I can envision two fixes:
a. Make this invisible file a named (regular) file, so it can
be deleted with "rm".
b. shmalloc etc checks the free disk space availabe in $TMPPATH
before doing an allocation.
The following program (from another Sequent user) will demonstrate
the problem. (Set TMPPATH to point to any directory will
little free disk space.)
*WARNING*: You will need to reboot your machine once $TMPPATH is full!!!
> /*
> ** Will allocate one megabyte shared memory at a time until the disk is full
> ** and then hang.
> */
> #include <stdio.h>
> #include <parallel/parallel.h>
>
> shared int *HUGE;
>
> main()
> {
> int i = 0;
>
> system("df $TMPPATH");
>
> while (1) {
> if (!(HUGE = (int *) shmalloc(1024 * 1024);)) {
> puts("No mem");
> exit(1);
> }
> printf("%d\n", ++i); /* Report progress (?) */
> }
> }
Kinson Ho (ho@ginger.Berkeley.EDU)
Computer Science Division
University of California, Berkeley