In message <[EMAIL PROTECTED]>, "David E. Cross" writes:
>though. Especially confusing is the following sequence of events:
>
> 41096 ypserv CALL select(0x10,0x8051040,0,0,0xbfbff518)
> 41096 ypserv PSIG SIGCHLD caught handler=0x804c75c mask=0x0 code=0x0
...
> 41096 ypserv RET sigretur
> > 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 cr
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,
>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 t
:We have still have a problem with PR #10971 here running a -STABLE as of last
:week. (Long since 10971 should have been dead). It is a difficult problem
:to track down as stack corruption makes debugging files less than useless.
:I do, however, have a ktrace of an entire transaction that causes
We have still have a problem with PR #10971 here running a -STABLE as of last
week. (Long since 10971 should have been dead). It is a difficult problem
to track down as stack corruption makes debugging files less than useless.
I do, however, have a ktrace of an entire transaction that causes yps
6 matches
Mail list logo
