Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-WM-Posted-At: avacado.atomice.net; Wed, 22 May 02 22:27:34 +0100
Message-ID: <001501c201d7$7d1f60c0$0100a8c0@advent02>
From: "Chris January" <chris AT atomice DOT net>
To: <cygwin AT cygwin DOT com>
References: <003301c201c7$06f822c0$0100a8c0 AT advent02> <20020522202454 DOT GA20138 AT redhat DOT com>
Subject: Re: Question about tty.cc
Date: Wed, 22 May 2002 22:27:34 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000


> >I've tracked down the "dup(/dev) failed" on startup error to the
following
> >section of code in tty.cc :
> >
> >      char buf[40];
> >
> >      __small_sprintf (buf, "cygwin.find.console.%d", myself->pid);
> >      SetConsoleTitle (buf);
> >      Sleep (40);
> >      console = FindWindow (NULL, buf);
> >      SetConsoleTitle (oldtitle);
> >      Sleep (40);
> >      ReleaseMutex (title_mutex);
> >      if (console == NULL)
> > {
> >   termios_printf ("Can't find console window");
> >   return -1;
> > }
> >
> >Can anyone tell me what the Sleep (40) lines are there for? If they are
> >there to give the console window time to appear, may I suggest the delay
is
>
> You could suggest that but you'd need a lot more justification.  The code
> in question is many years old.
>
> It's not obvious to me how this translates into an "unable to dup" error.
No - it wasn't obvious for me, that's why it took so long to track down...
:-)
The short story is the dup error always occurs when the "Can't find console
window" error is generated.
The long story is that in these circumstances the window takes longer than
usual to appear, hence FindWindow returns NULL, hence allocate_tty
returns -1, hence attach_tty returns -1, hence myself->ctty gets set to -1,
hence in get_devn() in path.cc, the macro real_tty_attached returns false,
and because myself.ctyy < 0, devn gets set to FH_BAD.
Hence, when dtable::init_std_file_from_handle() calls
build_fhandler_from_name which calls path_conv::check, path_conv::check sees
the FH_BAD returned from get_devn and tries to open C:\Cygwin\dev\tty which
fails.
This means a fhandler gets built with the incorrect win32 filename
(C:\Cygwin\dev\tty instead of \dev\tty1) and the incorrect fhandler type
(FH_DISK instead of FH_TTYS). When dup is called, build_fhandler is called
to build the new fhandler and then the dup method of the old fhandler is
called. However in this case fhandler_base::dup gets called because the
fhandler is of the wrong type, rather than one of the dup methods in
fhandler_tty.cc. Because fhandler_base::dup doesn't understand how to
duplicate tty handles correctly, the method fails and the error I see on the
screen is the result.

Regards
Chris





--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/