Resource temporarily unavailable

[gerard patel]

On Wed, 05 Dec 2001 10:34:05 +0000, "T REX" <the1trex at hotmail.com>
wrote:

>hmm, I ran a +relay,+seh. results can be found at:
>http://www.termografinett.no/wine.log2.bz2
>
>if you want to try the program, I upploaded it here:
>http://www.termografinett.no/thinkboxx.tar.gz
>its 1MB.

That will not be necessary, the mystery is solved.

0806d8a0:Call
kernel32.ReadFile(00000078,4124fdb0,00000400,40616958,4124a5f0)
ret=0043ecff
0806d8a0:Ret  kernel32.ReadFile() retval=00000000 ret=0043ecff
0806d8a0:Call
kernel32.GetOverlappedResult(00000078,4124a5f0,40616958,00000001)
ret=0043ed17
trace:seh:EXC_RtlRaiseException code=c000013a flags=00y

Exception c000013a means that you typed Ctrl C to exit
Wine. The Wine debugger could hardly start in this situation.

As of why the application hangs, well, it's waiting to 1024
bytes of data to get to it through the serial link.

The Wine problem is that the data does not come up on
the serial link. The application problem is that it hangs
when no data comes in as expected. A well written application
should not hang because data is not available on the 
serial link, of course. 

To come back to the Wine problem, I see nothing that the
app did that could trigger the device to output its 1024
bytes of data, so I think that the device is monitoring the
serial data link state and outputting data as soon as some
state is reached. I'm afraid that the reason that the device
don't do it could be (from your previous trace) :

0806d898:Call kernel32.CreateFileA(42fbbdd8
"COM1",c0000000,00000000,00000000,00000003,40000000,00000000)
ret=0043ddf8
trace:file:CreateFileA COM1 GENERIC_READ GENERIC_WRITE OPEN_EXISTING
trace:file:CreateFileA opening device 'COM1'
trace:file:DOSFS_CreateCommPort COM1 c0000000 40000000
0806d898:Ret  kernel32.CreateFileA() retval=00000060 ret=0043ddf8
0806d898:Call kernel32.SetCommTimeouts(00000060,406150f0) ret=0043de48
trace:comm:SetCommTimeouts (60,0x406150f0)
0806d898:Ret  kernel32.SetCommTimeouts() retval=00000001 ret=0043de48
0806d898:Call kernel32.BuildCommDCBA(42fbb0f4 "COM1
96,n,8,1",406150ac) ret=0043dfc3
trace:comm:BuildCommDCBAndTimeoutsA (COM1 96,n,8,1,0x406150ac,(nil))
trace:comm:COMM_BuildOldCommDCB (COM1 96,n,8,1), ptr 0x406150ac
trace:comm:COMM_BuildOldCommDCB baudrate (9600)
trace:comm:COMM_BuildOldCommDCB parity (N)
trace:comm:COMM_BuildOldCommDCB charsize (8)
trace:comm:COMM_BuildOldCommDCB stopbits (1)
0806d898:Ret  kernel32.BuildCommDCBA() retval=00000001 ret=0043dfc3ü
0806d898:Call kernel32.SetCommState(00000060,406150ac) ret=0043e017
trace:comm:SetCommState handle 96, ptr 0x406150ac
trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0
stopbits 1
trace:comm:SetCommState ~IXON ~IXOFF
trace:comm:SetCommState CRTSCTS
warn:comm:SetCommState DSR/DTR flow control not supported
0806d898:Ret  kernel32.SetCommState() retval=00000001 ret=0043e017

'flow control not supported'. This could be the reason. 
I have no idea why it's not supported - I suspect a system-related
reason, if  there is no api available to managed this stuff in the
Linux Api, for example.

Gerard