This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about tty.cc



> >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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]