On Sun, Jun 21, 2009 at 1:03 PM, Erich Hoover <span dir="ltr"><<a href="mailto:ehoover@mines.edu">ehoover@mines.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Sun, Jun 21, 2009 at 10:23 AM, Erich Hoover <span dir="ltr"><<a href="mailto:ehoover@mines.edu" target="_blank">ehoover@mines.edu</a>></span> wrote:<br>
</div><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><div>On Sun, Jun 21, 2009 at 1:36 AM, Damjan Jovanovic <span dir="ltr"><<a href="mailto:damjan.jov@gmail.com" target="_blank">damjan.jov@gmail.com</a>></span> wrote:<br>
</div></div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div>...<br></div></blockquote></div><div class="im"><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Maybe the memory is writable but not readable, and<br>
WSARecvFrom()/recv() is reading it while memcpy() is not?�<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Maybe the memory is from a DIB section which Wine lazily mprotects and<br>
the kernel isn't raising SIGSEGV for the protection to be reapplied?<br>
Does simply zero-filling buf before calling WSARecvFrom() help?<br>
</blockquote></div></div></div><div class="im"><br>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.<br>
<br>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:<br>0009:Call KERNEL32.VirtualAlloc(01b85000,00040000,00001000,00000004) ret=79e74a2b<br>
0009:Ret� KERNEL32.VirtualAlloc() retval=01b85000 ret=79e74a2b<br>0009:Call ws2_32.recv(00000380,01ba4fc1,000178d0,00000000) ret=0036a287<br>...<br></div></blockquote></div><br>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?<div><div></div><div class="h5"><br><br>
Erich Hoover<br><a href="mailto:ehoover@mines.edu" target="_blank">ehoover@mines.edu</a><br>
</div></div></blockquote></div><br>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.<br>
<br>Erich Hoover<br><a href="mailto:ehoover@mines.edu">ehoover@mines.edu</a><br>