Package: hurd
Version: current
Hi,
this is really a nice obscure bug.
Calling proc_getprocinfo on PID 4 (root filesystem server) causes proc
to leak a couple of kilobytes (pages?) each time. This can easily be
reproduced by
ps -F hurd 0
ps -F hurd 4
ps -F hurd 0
etc. Do this right after boo
It sounds like there are no signals that should be happening.
Try setting a breakpoint in hurdselect.c right after it gets the reply
message, and break if MSGERR or MSG.error.err is nonzero.
Hmm. It doesn't look like _hurd_select deals at all right with signals
interrupting the block. This wil
On Sat, Jun 23, 2001 at 12:10:26PM -0600, Gordon Matzigkeit wrote:
> I don't think this is insurmountable. We could simply avoid the text
> comparison for such functions, assuming that their text will be
> completely different from the source. For some functions, we can
> still do the right thin
On Tue, Jun 26, 2001 at 04:16:54AM -0400, Roland McGrath wrote:
> Unless the program is using sigaction without SA_RESTART for its signal
> handlers, select should not return EINTR (it should restart). So the
> things to figure out are: what all kinds of signal handling is it using,
> and what si
Unless the program is using sigaction without SA_RESTART for its signal
handlers, select should not return EINTR (it should restart). So the
things to figure out are: what all kinds of signal handling is it using,
and what signals might be generated that you would expect.
___
