This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: snapshot now == 1.5.7 soon, please try
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 <ford@vss.fsi.com>
>
> * 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/