This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: poll() on cygwin sometimes fails [PATCH]
Type: Stage:
Components: Extension Modules Versions: 3rd party
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: georg.brandl, nnorwitz, warner, zooko
Priority: normal Keywords:

Created on 2007-07-25 00:58 by warner, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
cygwin-poll.diff warner, 2007-07-25 00:58 patch for selectmodule.c
Messages (6)
msg32549 - (view) Author: Brian Warner (warner) Date: 2007-07-25 00:58
While trying to track down a problem with our application (http://allmydata.org) running under cygwin, I discovered that the select.poll() object sometimes returns completely bogus data. poll() returns a list of tuples of (fd, revent), but fds are supposed to be small integers, and revents are a bitmask of POLLIN/POLLOUT flags. In my tests, I saw poll() return a list that started out looking normal, but the last half of the list contained fds and revents values like fd=0x7672a646, revent=0xd819. 

It turns out that under cygwin-1.5.24 (which I believe is a pretty recent version), the poll() call sometimes violates the POSIX specification, and provides a return value which is different than the number of pollfd structures that have non-zero .revents fields (generally larger). This causes the implementation of poll_poll() (in Modules/selectmodule.c) to read beyond the end of the pollfd array, copying random memory into the python list it is building, causing the bogus values I observed during my tests.  

These bogus values were mostly ignored, because the Twisted pollreactor that I was using noticed that the fd didn't correspond to any previously-registered file descriptor. It was only when the bogus fd happened to coincide with a real one (and when that indicated that a TCP listening socket became writable, which should never happen) that an exception was raised.

 The attached patch (against 2.5.1) works around the problem by manually counting the number of non-zero .revents, rather than relying upon the return value from poll(). This version passes test_poll on both linux and cygwin.

cheers,
 -Brian Warner


msg32550 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2007-07-25 05:53
Has this problem been reported to cygwin?  Have they fixed the problem?
msg32551 - (view) Author: Brian Warner (warner) Date: 2007-07-27 23:25
We've begun the process: zooko is working on a patch for cygwin and is working with them to figure out how to compile the thing. We've not yet explained the poll() bug to them in detail (wanting to have a patch in hand first).

I'll report back once we get some word from them about how likely it is this problem will be fixed on the cygwin side.
msg32552 - (view) Author: Zooko O'Whielacronx (zooko) Date: 2007-08-01 23:08
FYI, this is the issue ticket on the allmydata.org Tahoe project:

http://allmydata.org/trac/tahoe/ticket/31

I've written a patch for cygwin poll and am now testing it before submitting it to the cygwin developers.
msg60166 - (view) Author: Zooko O'Whielacronx (zooko) Date: 2008-01-19 14:19
This bug was fixed in cygwin 1.5.25-7, released 2007-12-17.
msg62843 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-02-23 23:26
Closing as 3rd party, then.
History
Date User Action Args
2022-04-11 14:56:25adminsetgithub: 45241
2008-02-23 23:26:49georg.brandlsetstatus: open -> closed
nosy: + georg.brandl
messages: + msg62843
versions: + 3rd party, - Python 2.5
2008-01-19 14:19:25zookosetmessages: + msg60166
2007-07-25 00:58:03warnercreate