wild pointers in current named pipe implementation?

Bill Medland billmedland at mercuryspeed.com
Mon Apr 14 18:02:26 CDT 2003


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

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

-- 
Bill Medland
ACCPAC International, Inc.
medbi01 at accpac.com
Corporate: www.accpac.com
Hosted Services: www.accpaconline.com



More information about the wine-devel mailing list