On Sun, Jun 21, 2009 at 10:23 AM, Erich Hoover <ehoo...@mines.edu> wrote:
> On Sun, Jun 21, 2009 at 1:36 AM, Damjan Jovanovic <damjan....@gmail.com>wrote:
>
>> ...
>>
> Maybe the memory is writable but not readable, and
>> WSARecvFrom()/recv() is reading it while memcpy() is not?
>>
>
>> Maybe the memory is from a DIB section which Wine lazily mprotects and
>> the kernel isn't raising SIGSEGV for the protection to be reapplied?
>> Does simply zero-filling buf before calling WSARecvFrom() help?
>>
>
> The memory should be a buffer from the calling application that it is using
> temporarily to store update data before saving it to the hard-disk. Yes,
> oddly enough zero-filling the buffer before calling WSARecvFrom() also fixes
> the problem.
>
> So, where exactly should I be looking to find the real problem? As far as
> I can tell the memory for the buffer is being allocated immediate prior to
> the call and the request is for read/write access:
> 0009:Call KERNEL32.VirtualAlloc(01b85000,00040000,00001000,00000004)
> ret=79e74a2b
> 0009:Ret KERNEL32.VirtualAlloc() retval=01b85000 ret=79e74a2b
> 0009:Call ws2_32.recv(00000380,01ba4fc1,000178d0,00000000) ret=0036a287
> ...
>
After looking over the documentation for VirtualAlloc, it appears that Wine
should be zeroing the returned memory if MEM_COMMIT is specified. Making
this change (rather than playing around in the socket code) also fixes the
problem (see attached patch). Do you think this step occurs if write access
isn't specified?
Erich Hoover
ehoo...@mines.edu
diff --git a/dlls/ntdll/virtual.c b/dlls/ntdll/virtual.c
index 33918ca..be7ed24 100644
--- a/dlls/ntdll/virtual.c
+++ b/dlls/ntdll/virtual.c
@@ -1754,6 +1754,10 @@ NTSTATUS WINAPI NtAllocateVirtualMemory( HANDLE process, PVOID *ret, ULONG zero_
if (status == STATUS_SUCCESS)
{
+ /* A successful commit operation must zero the allocated memory */
+ if (type & MEM_COMMIT)
+ memset(base, 0, size);
+
*ret = base;
*size_ptr = size;
}
