Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com X-Authentication-Warning: eos.vss.fsi.com: ford owned process doing -bs Date: Wed, 21 Jan 2004 13:08:15 -0600 (CST) From: Brian Ford X-X-Sender: ford@eos To: cygwin@cygwin.com Subject: Re: snapshot now == 1.5.7 soon, please try In-Reply-To: <20040121183710.GA25477@redhat.com> Message-ID: References: <20040120230704.GA15076@redhat.com> <20040121170832.GA17823@redhat.com> <20040121182042.GA25111@redhat.com> <20040121183710.GA25477@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Reply-To: cygwin@cygwin.com This is just to prove that I'm not a total idiot :). I'll let this issue die now. On Wed, 21 Jan 2004, Christopher Faylor wrote: > On Wed, Jan 21, 2004 at 12:27:52PM -0600, Brian Ford wrote: > >On Wed, 21 Jan 2004, Christopher Faylor wrote: > >> Ok. So, I took ten minutes and debugged the problem myself and I'll > >> check in a fix. > >> > >Thank you. > > > >That is why I asked. You know your way around, so it takes you *much* > >less time. > > > This was only a little knowing my way around. It was really pretty > basic debugging. > > 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. > I got here fast by attaching with gdb and backtracing. Pretty simple. > Realizing that this function obviously wasn't supposed to be hanging, I > theorized that the com port wasn't being opened properly. > Not knowing the Windows API at all, that was not obvious to me. After all, the call was named WaitCommEvent. I did gather that the port wasn't being opened properly, though. I assumed that the nonblocking flag had gotten lost somewhere, and we weren't even supposed to be here. > 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. > Saw that. At this point, I started comparing strace output from 1.5.5 with 1.5.7. Then, I got lost in some minor parameter differences to the open and CreateFile calls. There are some that I still don't understand. Strace printed the mode argument as 6 in 1.5.5 and 1 in 1.5.7. It is supposed to be 0, and was via gdb, in both cases. I'll see if I can figure out why. > I noticed that fhandler_base::open has special serial considerations. > I noticed this too, but failed to make the next leap (although I did briefly consider it). I was still puzzled by the above. > 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 > > * dtable.cc (build_fh_pc): Use DEV_SERIAL_MAJOR to catch all serial > ports. > In a way, that was just my dumb luck :^D. I do appreciate the explanation, though. And, I wouldn't have been able to extrapolate this fix to all applicable calls and devices that quickly. Anyway, thanks again. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 -- 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/