Since python version 3.7 (and some 3.6+ versions) regexp engine
changed to treat the wrong escape sequences as errors. Previously,
if the replace string had something like '\u0000', '\u' was
qualified as a bad escape sequence and treated just as a sequence
of characters '\' and 'u'. But know this triggers an error:
Traceback (most recent call last):
File "/usr/lib/python3.7/sre_parse.py", line 1021, in parse_template
this = chr(ESCAPES[this][1])
KeyError: '\\u'
From the documentation [1]:
Unknown escapes consisting of '\' and an ASCII letter in replacement
templates for re.sub() were deprecated in Python 3.5, and will now
cause an error.
We need to escape the backslash by another one to keep regexp engine
from errors. In case of '\\u000', '\\' is a valid escape sequence
and the 'u' is a simple character.
To be 100% safe we need to use 're.escape(replace)', but it escapes
too many characters making the logs hard to read.
This change fixes Python 3 tests on systems with python 3.7.
Should be backward compatible.
Reported-by: Ben Pfaff <email address hidden>
Signed-off-by: Ilya Maximets <email address hidden>
Signed-off-by: Ben Pfaff <email address hidden>
python: Catch setsockopt exceptions for TCP stream.
'sock.setsockopt' could throw exceptions. For example, if non-blocking
connection failed before the call:
Traceback (most recent call last):
File "../.././test-ovsdb.py", line 896, in <module>
main(sys.argv)
File "../.././test-ovsdb.py", line 891, in main
func(*args)
File "../.././test-ovsdb.py", line 604, in do_idl
ovs.stream.Stream.open(r))
File "/root/git_/ovs/python/ovs/stream.py", line 190, in open
error, sock = cls._open(suffix, dscp)
File "/root/git_/ovs/python/ovs/stream.py", line 744, in _open
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
File "/usr/local/lib/python2.7/socket.py", line 228, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 54] Connection reset by peer
netdev: Properly clear 'details' when iterating in NETDEV_QOS_FOR_EACH.
The function comment for netdev_queue_dump_next() said that it cleared its
'detail' argument, but it didn't actually do that, which meant that details
could be incorrectly carried along from one queue to the next.
netdev-linux: Avoid division by 0 if kernel reports bad scheduler data.
If the kernel reported a value of 0 for the second value in
/proc/net/psched, it would cause a division-by-zero fault in
read_psched(). I don't know of a kernel that would actually do that, but
it's still better to be safe.
Found by clang static analyzer.
Reported-by: Bhargava Shastry <email address hidden>
Signed-off-by: Ben Pfaff <email address hidden>
Reviewed-by: Yifeng Sun <email address hidden>
When I tried using ovs-tcpundump, I got the following error message:
Traceback (most recent call last):
File ./ovs-tcpundump, line 64, in <module>
if m is None or int(m.group(1)) == 0:
ValueError: invalid literal for int() with base 10: '00a0'
update_in_band_remotes() created an in-band manager and then tried to work
with it without first checking whether creation had succeeded. If it
failed, this led to a segfault.
