Repository navigation
test_socket failing in solaris #73455
Description
| BPO | 29269 |
|---|---|
| Nosy | @tiran, @blastwave |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2017-01-13.20:55:24.427>
labels = ['3.7', 'type-bug', 'tests']
title = 'test_socket failing in solaris'
updated_at = <Date 2020-08-04.16:01:56.392>
user = 'https://bugs.python.org/phantal'bugs.python.org fields:
activity = <Date 2020-08-04.16:01:56.392>
actor = 'vstinner'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Tests']
creation = <Date 2017-01-13.20:55:24.427>
creator = 'phantal'
dependencies = []
files = []
hgrepos = []
issue_num = 29269
keywords = []
message_count = 10.0
messages = ['285440', '296475', '296546', '301914', '374660', '374723', '374754', '374767', '374790', '374794']
nosy_count = 5.0
nosy_names = ['christian.heimes', 'petriborg', 'blastwave', 'phantal', 'Jim Crigler']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue29269'
versions = ['Python 3.7']
Activity
phantal commentedon Jan 13, 2017
I started looking into this failure to see if I could figure out why but it looks like I'd have to spend more time than I have available to figure out the cause.
Environment/setup:
When I run test_socket I see the following 4 failures; please note, I'm hand typing the results so I may typo something:
ERROR: testCount (test.test_socket.SendfileUsingSendfileTest)
Traceback:
File "(...)/test_socket.py", line 5248, in testCount
File "(...)/test_socket.py", line 5151, in recv_data
MemoryError
Error: testCount (test.test_socket.SendfileUsingSendfileTest)
Traceback:
File "(...)/test_socket.py", line 277, in _tearDown
File "(...)/test_socket.py", line 289, in clientRun
File "(...)/test_socket.py", line 5241, in _testCount
File "(...)/Lib/socket.py", line 296, in _sendfile_use_sendfile
socket.timeout: timed out
Error: testWithTimeout (test.test_socket.SendfileUsingSendfileTest)
Traceback:
File "(...)/test_socket.py", line 5318, in testWithTimeout
data = self.recv_data(conn)
File "(...)/test_socket.py", line 5151, in recv_data
chunk = conn.recv(self.BUFSIZE)
MemoryError
Error: testWithTimeout (test.test_socket.SendfileUsingSendfileTest)
Traceback:
File "(...)/test_socket.py", line 277, in _tearDown
raise exc
File "(...)/test_socket.py", line 289, in clientRun
test_func()
File "(...)/test_socket.py", line 5313, in _testWithTimeout
sent = meth(file)
File "(...)/Lib/socket.py", line 296, in _sendfile_use_sendfile
socket.timeout: timed out
Error: testCountWithOffset (test.test_socket.SendfileUsingSendfileTest)
Traceback:
File "(...)/test_socket.py", line 5287, in testCountWithOffset
self.assertEqual(len(data), count)
AssertionError: 4376231 != 100007
Ran 539 tests in 69.166s
FAILED (failures=1, errors=4, skipped=324)
test test_socket failed
JimCrigler commentedon Jun 20, 2017
I'm having the same problem with gcc 6.2.
Is there any update?
petriborg commentedon Jun 21, 2017
Getting the same test_socket errors on Solaris 11 with Python 3.5.3.
======================================================================
ERROR: testCount (test.test_socket.SendfileUsingSendfileTest)
----------------------------------------------------------------------
======================================================================
ERROR: testCount (test.test_socket.SendfileUsingSendfileTest)
----------------------------------------------------------------------
======================================================================
ERROR: testWithTimeout (test.test_socket.SendfileUsingSendfileTest)
----------------------------------------------------------------------
======================================================================
ERROR: testWithTimeout (test.test_socket.SendfileUsingSendfileTest)
----------------------------------------------------------------------
Ran 530 tests in 54.577s
FAILED (errors=4, skipped=315)
test test_socket failed
1 test failed again:
test_socket
vstinner commentedon Sep 11, 2017
Since it seems like Solaris is dying, I'm not sure that it still makes sense to fix Python issues specific to Solaris. Here, I don't understand the issue, no patch is proposed and I'm not really interested to investigate :-/
blastwave commentedon Aug 1, 2020
Well here we are in 2020 and Solaris systems are still running just fine. In fact, some big Fujitsu SPARC systems are running in production for years and years and also, no surprise, this test still fails horrifically on old stable Solaris 10. Python is turning into a piece of supposedly open source software with many commercial interests with their hands inside of it. I am not sure how to get this bug fixed but I can certainly report that it is still broken in 3.7.8 on a very stable and reliable platform.
phantal commentedon Aug 3, 2020
Solaris will be around for at least another 10-15 years.
The least you could do is look into it and offer some speculations.
tiran commentedon Aug 3, 2020
What do you expect us to do? No Python core dev has access to a Solaris machine. We cannot debug the issue and have to rely on external contributions. We have not declared Solaris as unsupported yet because people are still contributing fixes.
If you are looking for wild speculations: I guess Solari' sendfile() is either broken or does not behave like on other platforms.
vstinner commentedon Aug 3, 2020
Someone has to write a fix. You may contact Solaris vendor or a company using Solaris who wants to pay a developer to write a fix.
phantal commentedon Aug 4, 2020
Christian, you did exactly what I needed. Thank you.
I don't have the means to do a git bisect to find where it broke. It wasn't a problem around 3.3 timeframe and I'm not sure when this sendfile stuff was implemented.
The man page for sendfile says "The sendfile() function does not modify the current file pointer of in_fd, (...)". In other words the read pointer for the input descriptor won't be advanced. They expect you to use it like this:
... though making that change in posixmodule.c would break this test severely since the send & receive code is running on the same thread.
In posixmodule.c I don't see anything that attempts to return the number of bytes successfully sent. Since the input file descriptor won't have its read pointer advanced, the variable "offset" must be set to the correct offset value, otherwise it just keeps reading the first 32k of the file that was generated for the test.
phantal commentedon Aug 4, 2020
I accidentally hit submit too early.
I tried changing the code in posixmodule.c to use lseek(), something like the following:
do {
ret = sendfile(...);
} while( ... );
lseek( in, offset, SEEK_SET );
... however, in addition to readfile not advancing the file pointer it also doesn't seem to cause an EOF condition. In my first attempt at the above I was doing this after the loop:
lseek( in, offset, SEEK_CUR );
... and it just kept advancing the file pointer well beyond the end of the file and sendfile() had absolutely no qualms about reading beyond the end of the file.
I even tried adding a read() after the 2nd lseek to see if I could force an EOF condition but that didn't do it.
kulikjak commentedon Dec 6, 2023
I tried reproducing this with Python 3.5.3 on the current Oracle Solaris 11, and I couldn't do it.
Since this report, there has been a sendfile related fix (#85853, #22040 #22128), which fixed some issues, but the traces there looked different. But since then, we haven't seen any sendfile issues on either Oracle Solaris 11 or OpenSolaris forks (AFAIK; others helped me test the fix with SmartOS and OpenIndiana). I am wondering whether this might be related to the test machine setup?
The fix went into Python 3.9 and newer so you can try those.
vstinner commentedon Dec 6, 2023
Python 3.5 and 3.9 no longer accept bugfixes: https://devguide.python.org/versions/
If someone can reproduce the issue on recent Python versions, please open a new issue (with a link to this one). I close this issue.