Strange issue with recv in Launchpad Enhanced

Erich Hoover ehoover at mines.edu
Sun Jun 21 11:23:15 CDT 2009


On Sun, Jun 21, 2009 at 1:36 AM, Damjan Jovanovic <damjan.jov at gmail.com>wrote:

> On Sun, Jun 21, 2009 at 1:06 AM, Erich Hoover<ehoover at 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
ehoover at mines.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20090621/55bca14d/attachment.htm>


More information about the wine-devel mailing list