======================================================================
ERROR: testCmsgTruncLen0 (__main__.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/pep-488/Lib/test/test_socket.py", line 2956, in testCmsgTruncLen0
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0), maxdata=0)
  File "/Users/bcannon/Repositories/cpython/pep-488/Lib/test/test_socket.py", line 2937, in checkTruncatedArray
    len(MSG), ancbuf)
  File "/Users/bcannon/Repositories/cpython/pep-488/Lib/test/test_socket.py", line 1921, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
RuntimeWarning: received malformed or improperly-truncated ancillary data

Original title: "test_socket fails under -Werror"

These are long-time, normally non-fatal warnings when running test_socket on OS X with Python 3 independent of -Werror, introduced with the socket sendmsg() and recvmsg() feature in the changes for Issue6560 and a followup in Issue12958.  I guess we haven't followed up on them since.  I note that there is now an open issue (Issue20669) about a set of test_socket failures under OpenBSD including this case.  So perhaps this test behavior also has its origins in differences between BSD vs others, further complicated by subsequent divergence of the OS X network layer from its BSD origins.

Interestingly, because the warning does not normally cause a test failure (that is, without the Python -Werror option as used in this issue), the warning messages do not show up in the OS X buildbot logs at all because the buildbot test runs use the -m test (test.regrtest) -W option (not to be confused with the Python -W option).  Without -m test -W, the warnings do appear but, without Python -Werror, cause no failures.

In this test (and nearby ones), the receiver provides too little space to receive the file descriptors that are sent, so that the control message has to be truncated if it is to be received at all.  The warning may indicate that the cmsghdr struct received still claims that the message contains the full amount of data (so that socket.recvmsg() would overrun the buffer if it actually believed the cmsghdr).

With that in mind, you might want to check whether file descriptors that don't fit are still received (say the sender sends three file descriptors when the receiver only asks for two, and the receiver gets a control message saying it now has descriptors on numbers 3 and 4, but it also gets a file descriptor on number 5 which it isn't told about).  If they are, it's a kernel bug which could be used for denial of service by exhausting the receiving process' quota of file descriptors (and the warning would probably go away if it were fixed).

Duplicate Issue35092 notes that running the tests with -Werror turns these warnings into test failures.

In PR27512 I tried to make the test expect the warning, but then it fails on ubuntu, so this is not the right solution.