On Sun, Jun 21, 2009 at 1:03 PM, Erich Hoover <ehoo...@mines.edu> wrote:
> 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 > Any thoughts on this? Is there anything a "+relay" wouldn't catch that could occur between the call to KERNEL32.VirtualAlloc and the call to ws2_32.recv? This behavior (the memory area having to be cleared before the recv call) seems a tad on the odd side. Erich Hoover ehoo...@mines.edu
