snapshot now == 1.5.7 soon, please try

Christopher Faylor cgf-no-personal-reply-please@cygwin.com
Wed Jan 21 19:25:00 GMT 2004


On Wed, Jan 21, 2004 at 07:04:17PM -0000, Dave Korn wrote:
> 
>
>> -----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@vss.fsi.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".  

Huh?  I fixed the problem.  Why are you still theorizing about the
cause?  If you are starting a new discussion then don't piggyback on
this thread.

cgf

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



More information about the Cygwin mailing list