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.
Bill's patch, http://www.winehq.com/hypermail/wine-patches/2003/04/0164.html 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; release_object(user->pipe); + 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 :-)
- Dan