This is the mail archive of the cygwin 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: 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  <>
>         * (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:
Problem reports:

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