On Monday 14 April 2003 12:25 pm, Dan Kegel wrote:
I know Mike is planning to rewrite the named pipe implementation, but the current implementation could use a little love while we're waiting for the new one. So I'm looking into the recent user complaint about FlushFileBuffers and named pipes, in hopes I can find a very simple patch that will tide us over until the new named pipes code is ready (whenever that might be; Mike's busy on other things at the moment).
So I added an early call to FlushFileBuffers in the named pipe regression test (see attached patch). While poking around in wineserver, I found a few places where pointers were not set to NULL after being invalidated, and after I added the missing statements to set them to NULL, wineserver started behaving badly on the regression test. A run of wineserver under valgrind showed a null pointer access, so I added a couple null pointer check asserts (see attached patch). And sure enough, they fire.
So the question is -- did I screw up, or did I uncover a real issue? The answer will help me as I continue digging into the FlushFileBuffers named pipe bug report (and testing possible simple enhancements to the current named pipe implementation).
Thanks, Dan
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.
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,00000000,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
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.