wild pointers in current named pipe implementation?

[Gregory M. Turner]

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 at 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.

-- 
gmt

"Democracy is the theory that holds that the common people know
what they want, and deserve to get it good and hard." HL Mencken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pipe.c
Type: text/x-csrc
Size: 22367 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20030414/a1ae15e0/pipe.c