http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/3024/steps/test/logs/stdio

======================================================================
ERROR: test_article_head_body (test.test_nntplib.NetworkedNNTP_SSLTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_nntplib.py", line 251, in wrapped
    meth(self)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_nntplib.py", line 178, in test_article_head_body
    self.check_article_resp(resp, body, art_num)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_nntplib.py", line 158, in check_article_resp
    self.assertNotIn(article.lines[-1], (b".", b".\n", b".\r\n"))
IndexError: list index out of range

(...)
Re-running failed tests in verbose mode
Re-running test 'test_nntplib' in verbose mode
(...)
test_article_head_body (test.test_nntplib.NetworkedNNTPTests) ... ok

The last five builds have been successful so can this be closed as "out of date"?

> The last five builds have been successful so can this be closed as "out of date"?

Really? I saw a lot of test_nntplib failures this week, on Windows buildbots for example.

Well, it's not exactly the same error, but it's still "sporadic failure" of test_nntp. Example:

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8578/steps/test/logs/stdio


======================================================================
ERROR: test_zlogin (test.test_nntplib.NetworkedNNTPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_nntplib.py", line 251, in wrapped
    meth(self)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_nntplib.py", line 229, in test_zlogin
    user=baduser, password=badpw, usenetrc=False)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 704, in assertRaises
    return context.handle('assertRaises', callableObj, args, kwargs)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 162, in handle
    callable_obj(*args, **kwargs)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\nntplib.py", line 963, in login
    resp = self._shortcmd('authinfo user ' + user)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\nntplib.py", line 512, in _shortcmd
    return self._getresp()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\nntplib.py", line 450, in _getresp
    resp = self._getline()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\nntplib.py", line 433, in _getline
    line = self.file.readline(_MAXLINE +1)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\socket.py", line 514, in readinto
    raise OSError("cannot read from timed out object")
OSError: cannot read from timed out object

The timed out case seems to be similar to Issue 19756.

I presume the original report was due to testing when the server happened to return an article with an empty body. The failing test is

# XXX this could exceptionally happen...
self.assertNotIn(article.lines[-1], (b".", b".\n", b".\r\n"))

The test code already admits that what it is testing cannot be guaranteed (an article body could end with a full stop). And we have found another case where the test is not valid (an article with zero lines). I say remove this part of the test, at least when testing the article() and body() methods.

This just failed on 3.x (default) on koobs-freebsd{9,10} bots:

======================================================================
FAIL: test_article_head_body (test.test_nntplib.NetworkedNNTP_SSLTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_nntplib.py", line 240, in wrapped
    meth(self)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_nntplib.py", line 185, in test_article_head_body
    self.check_article_resp(resp, body, art_num)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_nntplib.py", line 165, in check_article_resp
    self.assertNotIn(article.lines[-1], (b".", b".\n", b".\r\n"))
AssertionError: b'.' unexpectedly found in (b'.', b'.\n', b'.\r\n')

----------------------------------------------------------------------

Full log attached

A few other buildbots shared this failure. It would be nice to see what the article is that is causing the failure, but I’m fairly confident we should just remove this part of the test.

I played with the server and group that is apparently used in the test:

>>> server = NNTP_SSL("nntp.aioe.org")
>>> [_, _, first, last, _] = server.group("fr.comp.lang.python")
>>> first
2900
>>> last
2915
>>> server.body(last)[1].lines[-1]
b''
>>> server.body(first)[1].lines[-1]
b'Merci'
>>> server.body(last - 1)[1].lines[-1]
b'Kevin'

I tried all articles from 2900–2915, and none of them end with a dot on its own line, so I don’t actually know what caused the failure.

However looking again at the _getlongresp() implementation, I cannot imagine how the test failure can occur except for a genuine body that ends with a dot on its own line (encoded as b".." and then converted to b"."). Here is a quick patch to alter the test cases.

This version actually works :P

Sorry, I lost track of this issue. What is the status?

@Martin: Do you want to convert your latest patch into a PR?

It looks like I was fairly confident about my patch, but it was all theoretical and I was never able to analyze the failure myself.

Sorry but I am unlikely to spend much time on this or open a pull request any time soon.

Victor opened Issue 32128 with the same complaint. I think I found the offending article:

>>> server = NNTP_SSL("nntp.aioe.org")
>>> [response, count, first, last, name] = server.group("comp.lang.python")
>>> last
199267
>>> pprint(server.article(199265)[1].lines)
[. . .
 b'Date: Fri, 24 Nov 2017 15:44:26 -0800 (PST)',
 . . .
 b'Message-ID: <dcaddc9c-a7b7-4120-bd30-304f58566d3d@googlegroups.com>',
 b'Subject: Re: Python loop and web server (bottle) in the same script (Posting',
 b'     On Python-List Prohibited)',
 . . .
 b'Content-Transfer-Encoding: quoted-printable',
 . . .
 b'If processing is I/O bound and not CPU bound, then asyncio should work fine=',
 b'.']

The body uses Quoted-printable encoding, and the previous line ends with an equals sign “=”, meaning a soft line break. So the full stop is on its own because the encoder didn’t want to fit it on the previous line. This is valid (albeit quirky) encoding, and not a problem with the NNTP library.

I suggest to close the issue since the bug didn't show up recently.

The test_article_head_body test is now skipped unconditionally:

    @unittest.skipIf(True, "FIXME: see bpo-32128")

I don't think we should close this issue without re-enabling that test.

>  I don't think we should close this issue without re-enabling that test.

The fact is that nobody cares of test_nntplib: this issue is open for 5 years. I don't see how leaving the issue open which helps. It's fine to skip a test if nobody is available to fix it.

Well, no one is going to notice it if we close this issue. I don't see why the age of the issue matters here. We close issues when we fix them. It may take 20 minutes, 5 years or a decade.

I understand closing an issue as "out of date" when we couldn't find the root of the problem, but in this case the problem is obvious and there is already a patch that tries to fix it.

Could anybody make a PR from these patches? @vstinner, would you make me a review if I do it?

See also: https://bugs.python.org/issue40735 (test_with_statement)