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
From: "Dave Korn" <dk AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: snapshot now == 1.5.7 soon, please try
Date: Wed, 21 Jan 2004 19:04:17 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20040121183710.GA25477@redhat.com>
Message-ID: <NUTMEGcISPim9OciPXk0000017e@NUTMEG.CAM.ARTIMI.COM>
X-OriginalArrivalTime: 21 Jan 2004 19:04:18.0139 (UTC) FILETIME=[5EA59AB0:01C3E051]

 

> -----Original Message-----
> From: cygwin-owner On Behalf Of Christopher Faylor

> The code was hanging in read.  So, I set a breakpoint in 
> readv, which, on code inspection, is what read calls.  Single 
> stepping along, I came to the function that was hanging.  
> Tracing that along I came to the Windows API function that 
> was hanging.  Realizing that this function obviously wasn't 
> supposed to be hanging, I theorized that the com port wasn't 
> being opened properly.  So, I set a breakpoint on 
> fhandler_serial::open and notice nothing special there.  Then 
> I noticed that fhandler_serial::open calls 
> fhandler_base::open.  I noticed that fhandler_base::open has 
> special serial considerations.  Stepping over those, I saw 
> they weren't being exercised.  So I fixed that using the same 
> technique you used here:
> 
> 2003-11-12  Brian Ford  <ford AT vss DOT fsi DOT com>
> 
>         * dtable.cc (build_fh_pc): Use DEV_SERIAL_MAJOR to 
> catch all serial
>         ports.
> 
> cgf

  Looking at diffs between the strace output from the earlier version of
that report [ http://www.cygwin.com/ml/cygwin/2004-01/msg00167.html ], I
noticed one thing: the underlying windoze device name opened by cygwin
corresponding to /dev/com1 used to be referred to as "\\.\com1", but
nowadays it's become "\.\com1".  

  IIUIC the original form is more correct, but both versions seem to be
valid from the DOS command line.

  A) It looks like some quoting or escaping has gone astray in the
gendevices part of the build procedure, doesn't it ?  I suspect the extra
backslash of being stripped by the shell.  I haven't yet been able to
determine exactly what change in the CVS history could be responsible for
this yet.

  B) Are any string comparisons ever done on the win32 version of the device
path?  Those might be failing if they expect both backslashes.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/