wild pointers in current named pipe implementation?

Bill Medland billmedland at mercuryspeed.com
Mon Apr 14 14:20:47 CDT 2003


Very a-propos.  I was just about to post on a related topic.

On April 14, 2003 10:25 am, 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).

I submitted a very simple patch; Alexandre is not accepting it until I do 
something about the error code (which is what I was about to ask about)

My view is that at least we should not have the wine server crash as a result.

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

Well, yes you did uncover a real issue.  If the (named pipe server process) 
writes, flushes (which should block), disconnects and closes then the 
pipe_user_destroy will trigger (reasonable) which deletes the client's fd.  
Then the (named pipe) client runs and tries to read from it's handle, but 
there is no fd for it.  The pipe_user_get_fd will segv.

>
> Thanks,
> Dan

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