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