On April 14, 2003 01:26 pm, Gregory M. Turner wrote:
On Monday 14 April 2003 12:25 pm, Dan Kegel wrote:
snip
I'm looking at the same stuff, since it's hard for me to proceed without working pipes. Bill's recent post to patches looks promising, I'll give it a try and get back to the list.
NB. My patch only stops the worst excesses of the problem. If the named pipe client tries to read from the pipe after the named pipe server has closed it then the ReadFile returns ERROR_PIPE_NOT_CONNECTED (or something like that).
It does nothing about the fact that the named pipe server should be able to call FlushFile in order to ensure that he client has finished reading the pipe.
You can see the error by running wineserver -f -p under gdb or ddd and running the attached replacement for dlls/kernel/tests/pipe.c (which comes from your website Dan).
Here is a "+relay" dump on the client side:
greg@bad-penguin tests $ wine --debugmsg +relay kernel32_test.exe.so pipe 0009:Call PE DLL (proc=0x40620a00,module=0x40600000 (kernel32.dll),type=1,res=0x1) 0009:Ret PE DLL (proc=0x40620a00,module=0x40600000 (kernel32.dll),type=1,res=0x1) retval=1 0009:Starting process F:\src\wine\wine.test\dlls\kernel\tests\kernel32_test.exe (entryproc=0x40355000) 0009:Call kernel32.TlsAlloc() ret=403830e6 0009:Ret kernel32.TlsAlloc() retval=00000000 ret=403830e6 0009:Call kernel32.TlsGetValue(00000000) ret=40382b6f 0009:Ret kernel32.TlsGetValue() retval=00000000 ret=40382b6f 0009:Call ntdll.RtlAllocateHeap(40230000,00000008,00000010) ret=40382bad 0009:Ret ntdll.RtlAllocateHeap() retval=40231a70 ret=40382bad 0009:Call kernel32.TlsSetValue(00000000,40231a70) ret=40382bc4 0009:Ret kernel32.TlsSetValue() retval=00000001 ret=40382bc4 (null):0:test 1 of 4: 0009:Call kernel32.CreateNamedPipeA(40394434 "\\.\PiPe\tests_pipe.c",00000003,00000000,00000001,00000400,00000400,00 000000,00000000) ret=4037993a 0009:Ret kernel32.CreateNamedPipeA() retval=00000018 ret=4037993a 0009:Call kernel32.TlsGetValue(00000000) ret=40382b6f 0009:Ret kernel32.TlsGetValue() retval=40231a70 ret=40382b6f 0009:Call kernel32.TlsGetValue(00000000) ret=40382b6f 0009:Ret kernel32.TlsGetValue() retval=40231a70 ret=40382b6f 0009:Call kernel32.TlsGetValue(00000000) ret=40382b6f 0009:Ret kernel32.TlsGetValue() retval=40231a70 ret=40382b6f 0009:Call kernel32.WriteFile(00000018,405c2e0c,0000000b,405c2de8,00000000) ret=403799ac
There was a connect in there somewhere wasn't there, even if it isn't in the trace?
The call to WriteFile pretty much goes as expected on the server side, up to and including the call to grab_object; but when grab_object returns, the IP ends up somewhere surprising, and quickly jumps back into grab_object, this time, apparently with the NULL argument... although I start seeing some inconsistient results from the ddd now, which bizarrely claims that obj is /not/ NULL!
I wonder if there is some stack corruption, or a compiler optimization bug? There is a function pointer call in the stack, using the get_obj_fd inline function... but the inline is fine, spelling out it's meaning in get_handle_fd_obj has the same result. Wierd. Oh well... maybe Bill has already cracked this nut... will try his patch.