wild pointers in current named pipe implementation?

Gregory M. Turner gmturner007 at ameritech.net
Mon Apr 14 15:26:29 CDT 2003

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 
0009:Ret  PE DLL (proc=0x40620a00,module=0x40600000 
(kernel32.dll),type=1,res=0x1) retval=1
0009:Starting process 
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 
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) 

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.


"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

More information about the wine-devel mailing list