On Wed, 31 May 2000, David E. Cross wrote:
> > If you can reproduce the problem regularly then I recommend putting
> > a signal guard in to see if the corruption is being caused by the
> > signal interrupting at an inausipcious moment.
> >
> > In main() block SIGHUP, SIGINT, SIGTERM, and SIGCHLD using sigsetmask().
> >
> > Just prior to the select call unblock the signals.
> >
> > Just after the select call reblock the signals.
> >
> > And see if the corruption still occurs. If this fixes the problem,
> > then there is probably something in the reaper() (in yp_main.c)
> > that is causing corruption, probably by ripping a structure out from
> > under whatever piece of code the signal happens to interrupt.
> >
> > I took a quick look at the code and as far as I can tell it implements
> > no guards whatsoever. The inetd code had similar problems in the past.
>
> Alas, this is not something I have been able to reliably reproduce, it seems
> to trigger itself every so-often (and at inconvienient times). But no
> matter what I do by myself it will not trip.
Is it possibly related to a low-memory situation? I'm trying to solve a
problem in cron that sounds similar, and seems to be triggered when the
machine goes into swapping. I'm unable to duplicate it myself :-(
Guy
Guy Helmer, Ph.D. Candidate, Iowa State University Dept. of Computer Science
Research Assistant, Dept. of Computer Science --- [EMAIL PROTECTED]
http://www.cs.iastate.edu/~ghelmer
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
