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 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><div></div><div>On Sun, Jun 21, 2009 at 1:06 AM, Erich Hoover<<a href="mailto:ehoover@mines.edu" target="_blank">ehoover@mines.edu</a>> wrote:<br>
> I'm trying to track down an issue with Launchpad Enhanced were it fails to<br>
> download its updates (Bug #17443).� It appears that the issue stems from<br>
> recv being called with a buffer from a different process, so as a result the<br>
> call fails.� I put together a hack that gets around the problem<br>
> (<a href="http://bugs.winehq.org/show_bug.cgi?id=17443#c2" target="_blank">http://bugs.winehq.org/show_bug.cgi?id=17443#c2</a>), but I'm having difficulty<br>
> figuring out exactly why this is happening in the first place.� Does anyone<br>
> know if this is a known difference between Windows and Linux or if there is<br>
> something else strange going on?<br>
<br>
</div></div>If recv() fails with EFAULT, why doesn't the memcpy() in your patch<br>
raise SIGSEGV instead?<br>
</blockquote><div><br>While I realize now that I didn't exactly state this, that's why I thought the issue I was encountering was strange.<br><br></div><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 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><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>
<br>Erich Hoover<br><a href="mailto:ehoover@mines.edu" target="_blank">ehoover@mines.edu</a><br>