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