Strange issue with recv in Launchpad Enhanced

Erich Hoover ehoover at mines.edu
Thu Jun 25 19:19:10 CDT 2009


On Sun, Jun 21, 2009 at 1:03 PM, Erich Hoover <ehoover at mines.edu> wrote:

> On Sun, Jun 21, 2009 at 10:23 AM, Erich Hoover <ehoover at mines.edu> wrote:
>
>> On Sun, Jun 21, 2009 at 1:36 AM, Damjan Jovanovic <damjan.jov at 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
> ehoover at 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
ehoover at mines.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20090625/ce17a260/attachment-0001.htm>


More information about the wine-devel mailing list