Re: [9fans] odd out-of-memory behavior

[erik quanstrom <quanstro@coraid.com>]

unfortunately or fortunately this is a rare problem.
hopefully the caching upas will mature faster than
our mailboxes grow.

thanks for re-pointing out the acid tricks.  i shall
lay a trap.  but in the interest of covering the careful
thought bit ...

> /sys/src/9/port/proc.c:/^killbig marks the process
> to be killed, but if it can't acquire the lock on that
> process's segments, the memory is not actually
> freed immediately:
>
> 	kp->procctl = Proc_exitbig;
> 	for(i = 0; i < NSEG; i++) {
> 		s = kp->seg[i];
> 		if(s != 0 && canqlock(&s->lk)) {
> 			mfreeseg(s, s->base, (s->top - s->base)/BY2PG);
> 			qunlock(&s->lk);
> 		}
> 	}
>
> Perhaps another upas/fs proc sharing the same
> segment is holding the segment lock and
> blocking on something else.

how would that happen?  upas/fs -p doesn't fork.
(it's being run from imap4d.)

is there some other reason that segments would
be shared?

i originally thought someone else might be sitting
on the shared segments, but i couldn't explain how
that might be happening.  i also thought the purpose
of this loop was to hunt down relatives sharing memory
with killbig's vic:

	for(p = procalloc.arena; p < ep; p++) {
		if(p->state == Dead || p->kp)
			continue;
		if(p != kp && p->seg[BSEG] && p->seg[BSEG] == kp->seg[BSEG])
			p->procctl = Proc_exitbig;
	}

so much for the "careful" thought.  what am i missing?

- erik