Date: Thu, 4 Feb 1999 16:37:20 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@whistle.com> Cc: current@FreeBSD.ORG Subject: Re: Bug in piperd Message-ID: <199902050037.QAA91805@apollo.backplane.com> References: <199902042219.OAA90785@apollo.backplane.com> <36BA3B93.2781E494@whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:I've been seeng lockups in 3.0 where as is in piperd,
:but the stack trace has always looked as if the problem was in soft
:updates or the syncer daemon..
:
It's quite possible for as to be in 'piperd' when some other unassociated
crash occurs, since it is typically waiting for input from cc1. What
is not typical, however, is if as is stuck 'piperd' and the other end of
the pipe has been closed.
The particular piperd bug I found cannot crash the system - at worst it
will block a process forever. And you can still kill the process.
3.0's lockups could be very well due to a number of low-memory interlock
situations that typically occur when heavy paging is going on, if that is
how you are running 3.0. I suspect it is too late to get my getpbuf()
changes into 3.1, which might mitigate that somewhat.
-Matt
Matthew Dillon
<dillon@backplane.com>
:> The problem is simple (pseudo code fragment):
:>
:> pipe read:
:> ...
:> * check for EOF
:> * check for waiting writers
:> * lock the pipe
:> * check for waiting writers
:> * check for non-blocking I/O
:> * sleep in 'piperd'
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902050037.QAA91805>