wild pointers in current named pipe implementation?
dank at kegel.com
Mon Apr 14 22:40:00 CDT 2003
Gregory M. Turner wrote:
> 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). ...
> 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.
I highly recommend running wineserver under valgrind -- it found
the error much more reliably for me.
looks like a reasonable bandaid, at least. I don't know enough
about wineserver yet to say whether it's also a real fix.
I do recommend also applying this hunk from my patch in addition to Bill's:
--- server/named_pipe.c 4 Apr 2003 22:26:34 -0000 1.22
+++ server/named_pipe.c 14 Apr 2003 16:59:45 -0000
@@ -200,8 +201,11 @@
if (user->prev) user->prev->next = user->next;
else user->pipe->users = user->next;
if (user->thread) release_object(user->thread);
+ user->thread = NULL;
+ user->pipe = NULL;
if (user->fd) release_object( user->fd );
+ user->fd = NULL;
The irreproducibility went way down after applying this hunk.
It let me to reproduce the crash with much smaller test programs
(e.g. the one in my patch). (Possibly because it breaks wineserver --
as I said, I don't really understand it yet :-)
More information about the wine-devel