On Tue, 23 Jul 2002, Peter Wemm wrote:
> thread_zone = uma_zcreate("THREAD", sizeof (struct thread),
> thread_ctor, thread_dtor, thread_init, thread_fini,
> - UMA_ALIGN_CACHE, 0);
> + UMA_ALIGN_CACHE, UMA_ZONE_NOFREE);
> I haven't paniced yet with that change. :-) For some unknown reason,
> selwakeup() is dereferencing pointers to threads that have long gone and
> the backing store has been freed. The patch above is a bandaid, not a
> solution. It basically prevents threads ever being freed back to the
> general pool, even though everything here supposedly does not need that.
> (unlike struct proc and socket, for example).
Peter.. this comment in selrecord scared the heck out of me..
1151 * If the thread is NULL then take ownership of selinfo
1152 * however if the thread is not NULL and the thread points to
1153 * someone else, then we have a collision, otherwise leave it
1154 * as we've owned it in a previous selrecord on this selinfo.
it suggests that select still doesn't clean up after itself.
looking in select() however I see:
836 if (timo > 0)
837 error = cv_timedwait_sig(&selwait, &sellock, timo);
839 error = cv_wait_sig(&selwait, &sellock);
841 if (error == 0)
842 goto retry;
This suggests that there is no way to exit this function without
clearing the thread pointers but your trace suggests otherwise..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message