Serial comm overlapped IO problem

[Rein Klazes]

Hi,

Recent commits
http://www.winehq.com/hypermail/wine-cvs/2003/06/0232.html and
http://www.winehq.com/hypermail/wine-cvs/2003/07/0090.html

broke communication with my online banking program girotel.

Part of the +relay,+comm,+file,+server trace:

| 0009:Call kernel32.ClearCommError(000000bc,40721064,4072106c) ret=6005312f
| 0009: get_handle_fd( handle=0xbc, access=80000000 )
| 0009: get_handle_fd() = 0 { fd=16, type=1, flags=1 }
| trace:comm:ClearCommError handle 0xbc cbInQue = 375 cbOutQue = 0

ClearCommError indicates 375 bytes available.

| 0009: get_serial_info( handle=0xbc )
| 0009: get_serial_info() = 0 { readinterval=ffffffff, readconst=00000000, readmult=00000000, writeconst=00000000, writemult=00000000, eventmask=0000003d, commerror=00000000 }
| 0009: set_serial_info( handle=0xbc, flags=4, readinterval=00000000, readconst=00000000, readmult=00000000, writeconst=00000000, writemult=00000000, eventmask=00000000, commerror=00000000 )
| 0009: set_serial_info() = 0
| 0009:Ret  kernel32.ClearCommError() retval=00000001 ret=6005312f
| 0009:Call kernel32.ReadFile(000000bc,407210ac,00000177,40721060,4050358c) ret=60053164
| trace:file:ReadFile 0xbc 0x407210ac 375 0x40721060 0x4050358c

App. requests those 375 bytes.

| 0009: get_handle_fd( handle=0xbc, access=80000000 )
| 0009: get_handle_fd() = 0 { fd=16, type=1, flags=1 }
| 0009: register_async( handle=0xbc, type=1, overlapped=0x40503708, count=375, status=00000103 )
| 0009: register_async() = 0
| 0009:Ret  kernel32.ReadFile() retval=00000000 ret=60053164
| 0009:Call kernel32.GetLastError() ret=60053172
| 0009:Ret  kernel32.GetLastError() retval=000003e5 ret=60053172

Read returns failure with GLE() == ERROR_IO_PENDING, leading to an error
messagbox in the program.

With only the first commit, the ReadFile returns 1 (success) but no
data. Nowthe situations seems reversed, since accepting the error
message the program proceeds to the next read and a new error
messagebox.

Any suggestions?

Rein.

[Paul Rupe]

On 17 Jul 2003, [e-mail] wrote:
> http://www.winehq.com/hypermail/wine-cvs/2003/07/0090.html

This one was mine. :(
> > 0009: get_serial_info( handle=0xbc )
> > 0009: get_serial_info() = 0 { readinterval=ffffffff,
> > readconst=00000000, readmult=00000000, writeconst=00000000,
> > writemult=00000000, eventmask=0000003d, commerror=00000000 }
> > 0009: set_serial_info( handle=0xbc, flags=4, readinterval=00000000,
> > readconst=00000000, readmult=00000000, writeconst=00000000,
> > writemult=00000000, eventmask=00000000, commerror=00000000 )
> > 0009: set_serial_info() = 0
> > 0009:Ret  kernel32.ClearCommError() retval=00000001 ret=6005312f
> > 0009:Call kernel32.ReadFile
> > (000000bc,407210ac,00000177,40721060,4050358c) ret=60053164
> > trace:file:ReadFile 0xbc 0x407210ac 375 0x40721060 0x4050358c

I was looking at a similar problem yesterday with the Interact DexDrive (a 
Playstation memory card reader) software.  It does a set_serial_info with 
readinterval=ffffffff, readmult=ffffffff, readconst=5.  This of course 
causes all sorts of overflows when wineserver is computing the total 
timeout, but fixing that problem doesn't help.
> Read returns failure with GLE() == ERROR_IO_PENDING, leading to an
> error messagbox in the program.

It sounds like your app isn't expecting to do async reads at all.  Since it 
calls ClearCommError to find out how much data there is first, it probably 
wants ReadFile to block until it's read all of them.  As a hack, try 
commenting out the lines "else if (!(...)) *flags |= FD_FLAG_TIMEOUT;" from 
serial_get_info in server/serial.c.  I also hacked NtReadFile to do a quick 
non-blocking read before setting up all the async stuff.  That made 
DexPlorer work, but naturally broke everything else.
> With only the first commit, the ReadFile returns 1 (success) but no
> data.

That's good.  This is what my patch was intended to fix for sockets.
> Nowthe situations seems reversed, since accepting the error message
> the program proceeds to the next read and a new error messagebox.

I'm not sure what's happening here, but it does sound like the same problem 
I'm looking at with DexPlorer.  Hopefully someone who knows more about 
Wine's I/O can be more helpful than me.

[Mike McCormack]

Yes, that behaviour is wrong.  ReadFile() should not return 
ERROR_IO_PENDING unless it needs to wait for data.  If there is data 
there already, it should read the data normally and return success.

Mike

Rein Klazes wrote:
> ClearCommError indicates 375 bytes available.
> App. requests those 375 bytes.
> Read returns failure with GLE() == ERROR_IO_PENDING, leading to an error
> messagbox in the program.

[Eric Pouech]

Rein Klazes wrote:
> Hi,
>
> Recent commits
> http://www.winehq.com/hypermail/wine-cvs/2003/06/0232.html and
> http://www.winehq.com/hypermail/wine-cvs/2003/07/0090.html
>
> broke communication with my online banking program girotel.

does this patch help ?
A+

[Rein Klazes]

On Thu, 17 Jul 2003 20:38:12 +0200, you wrote:
> Rein Klazes wrote:
> > Hi,
> >
> > Recent commits
> > http://www.winehq.com/hypermail/wine-cvs/2003/06/0232.html and
> > http://www.winehq.com/hypermail/wine-cvs/2003/07/0090.html
> >
> > broke communication with my online banking program girotel.
>
> does this patch help ?

Yes, it works again now.

Thanks,

Rein.