Date: Thu, 20 Oct 2005 14:10:43 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: HASHI Hiroaki <hashiz@tomba.cskk-sv.co.jp> Cc: freebsd-i386@FreeBSD.org Subject: Re: i386/87208: /dev/cuad[0/1] bad file descriptor error during mgetty read Message-ID: <20051020140624.U99622@delplex.bde.org> In-Reply-To: <200510180933.j9I9XtQu026284@freefall.freebsd.org> References: <200510180933.j9I9XtQu026284@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Oct 2005, HASHI Hiroaki wrote:
> In this case, mgetty open a /dev/cuad? and dup(2) to stdin.
>
> int fd;
>
> fd = open(devname, O_RDWR | O_NDELAY | O_NOCTTY );
>
> /* make new fd == stdin if it isn't already */
>
> if (fd > 0)
> {
> (void) close(0);
> ---> if (dup(fd) != 0)
> {
> lprintf( L_FATAL, "mod: cannot make %s stdin", devname );
> return ERROR;
> }
> }
>
> Bad dup() was not return descriptor 0.
>
> Is this a dup(3)'s bug?
> (or imcompatible change?)
Looks like a bug in dup(2). dup(2) is documented to return the "lowest
numbered descriptor not in use by the process", and the close(0) should
ensure that descriptor 0 is not in use. The only visible bug in mgetty
is that it ignores errors in close(0); this breaks mainly the error
reporting.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051020140624.U99622>