[issue18528] Possible fd leak in socketmodule

Christian Heimes added the comment: OK, I'm rejecting it. -- resolution: -> rejected stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___

[issue18528] Possible fd leak in socketmodule

Antoine Pitrou added the comment: If none of use really understands the problem Coverity is trying to warn us about, I'd say "let languish or close". -- ___ Python tracker ___ _

[issue18528] Possible fd leak in socketmodule

Christian Heimes added the comment: The patch has been languishing for some time. Commit or close? -- ___ Python tracker ___ ___ Pytho

[issue18528] Possible fd leak in socketmodule

Christian Heimes added the comment: Shall I commit my patch or shall I close the coverity issue as intentionally? -- versions: -Python 3.3 ___ Python tracker ___ ___

[issue18528] Possible fd leak in socketmodule

Antoine Pitrou added the comment: > I don't understand why we would call accept() more than once. Because of EINTR? -- ___ Python tracker ___ ___

[issue18528] Possible fd leak in socketmodule

Changes by Serhiy Storchaka : -- nosy: -serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue18528] Possible fd leak in socketmodule

STINNER Victor added the comment: @pitrou: Does accept.patch look correct? I don't understand why we would call accept() more than once. -- ___ Python tracker ___ __

[issue18528] Possible fd leak in socketmodule

STINNER Victor added the comment: http://bugs.python.org/file31016/closesock3.patch looks overkill. For example, BEGIN_SELECT_LOOP already sets errno to 0. Here is a simpler patch. -- nosy: +haypo Added file: http://bugs.python.org/file31045/accept.patch __

[issue18528] Possible fd leak in socketmodule

Christian Heimes added the comment: Am 22.07.2013 16:00, schrieb Antoine Pitrou: > Have you tried to reset errno at the beginning of the function? It doesn't affect Coverity's report: BEGIN_SELECT_LOOP(s) Py_BEGIN_ALLOW_THREADS +errno = 0; timeout = internal_select_ex(s, 0, i

[issue18528] Possible fd leak in socketmodule

Christian Heimes added the comment: This patch does the trick. -- Added file: http://bugs.python.org/file31016/closesock3.patch ___ Python tracker ___ ___

[issue18528] Possible fd leak in socketmodule

Changes by Christian Heimes : Removed file: http://bugs.python.org/file31007/closesock2.patch ___ Python tracker ___ ___ Python-bugs-list mail

[issue18528] Possible fd leak in socketmodule

Changes by Christian Heimes : Removed file: http://bugs.python.org/file31004/closesock.patch ___ Python tracker ___ ___ Python-bugs-list maili

[issue18528] Possible fd leak in socketmodule

Antoine Pitrou added the comment: > Coverity may not understand the interaction with errno at all. Or it > may simple point out that some operating systems are not standard > conform and our assumption is not universally true. Have you tried to reset errno at the beginning of the function?

[issue18528] Possible fd leak in socketmodule

Christian Heimes added the comment: Coverity may not understand the interaction with errno at all. Or it may simple point out that some operating systems are not standard conform and our assumption is not universally true. Here is a patch that raises an exception when newfd != INVALID_SOCKET.

[issue18528] Possible fd leak in socketmodule

Antoine Pitrou added the comment: What if you add "errno = 0" at the beginning of the function? Perhaps Coverity is confused by the fact that we use CHECK_ERRNO() to infer whether accept() succeeded or not, rather than simply checking the return value. I don't like your patch, because it adds

[issue18528] Possible fd leak in socketmodule

Changes by Christian Heimes : -- nosy: +pitrou, serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue18528] Possible fd leak in socketmodule

New submission from Christian Heimes: Coverity claims that sock_accept() may leak a fd. I have been starring at the code for a while and I'm still not sure if Coverity is right. The macros make the code paths hard to follow. The attached patch is simple and should not be a performance issue.