[New-bugs-announce] [issue40297] test_socket.CANTest is broken at HEAD on master
Karl Ding
report at bugs.python.org
Wed Apr 15 23:25:02 EDT 2020
New submission from Karl Ding <karl.jw.ding at gmail.com>:
While working on https://bugs.python.org/issue40291, I was trying to run the SocketCAN tests to ensure that my changes weren't causing any regressions. However, I was seeing test failures at HEAD.
I'm running the tests like so:
# Kernel version
uname -r
# 5.4.23-1-MANJARO
# Load SocketCAN vcan kernel module
sudo modprobe vcan
# Start and set up a virtual SocketCAN interface
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0
# Run the socket tests using locally built python
./python -m unittest -v test.test_socket.CANTest
After bisecting, I discovered that the test started failing back in 2017, with the introduction of the ISOTP protocol. https://github.com/python/cpython/pull/2956/files#diff-a47fd74731aeb547ad780900bb8e6953L1376-R1391
Here, the address family (the second tuple item) is explicitly removed:
diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
index bf8d19fe2f..beadecfad5 100644
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -1373,9 +1373,22 @@ makesockaddr(SOCKET_T sockfd, struct sockaddr *addr, size_t addrlen, int proto)
ifname = ifr.ifr_name;
}
- return Py_BuildValue("O&h", PyUnicode_DecodeFSDefault,
- ifname,
- a->can_family);
+ switch (proto) {
+#ifdef CAN_ISOTP
+ case CAN_ISOTP:
+ {
+ return Py_BuildValue("O&kk", PyUnicode_DecodeFSDefault,
+ ifname,
+ a->can_addr.tp.rx_id,
+ a->can_addr.tp.tx_id);
+ }
+#endif
+ default:
+ {
+ return Py_BuildValue("O&", PyUnicode_DecodeFSDefault,
+ ifname);
+ }
+ }
}
#endif
This seems to be an intentional breakage, since the code in getsockaddrarg also operates on just the interface name, ignoring the address family.
if (!PyArg_ParseTuple(args,
"O&;AF_CAN address must be a tuple "
"(interface, )",
PyUnicode_FSConverter, &interfaceName))
As such, I believe the test should have been updated, but was missed during the ISOTP changes. Can someone (a core member?) confirm that this is the correct approach?
Note: However, this also implies that the CANTest test was never being run (either via CI on PRs or on the Buildbot cluster) and instead was always skipped, since I would've expected this failure to show up right away...
----------
components: Library (Lib)
messages: 366576
nosy: karlding
priority: normal
severity: normal
status: open
title: test_socket.CANTest is broken at HEAD on master
type: behavior
versions: Python 3.9
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40297>
_______________________________________
More information about the New-bugs-announce
mailing list