wild pointers in current named pipe implementation?

[Gregory M. Turner]

On Monday 14 April 2003 06:02 pm, Bill Medland wrote:
> 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.

ok.  given the surgical nature of the patch I didn't expect it to clean my 
room or walk my dogs... a non-crashing wineserver with bugs is fine by me if 
the alternative is a crashing wineserver.

> > 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,
> >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?

umm, not sure... glancing at your test code (test_DisconnectNamedPipe) I see 
no threads being spawned, and no np connect...  I might have mangled 
something... maybe I should make sure what I have still matches your 
website.... you test it under Win2K right?

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