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
