[issue34820] binascii.c:1578:1: error: the control flow of function ‘binascii_crc32’ does not match its profile data (counter ‘arcs’)
David Cuthbert added the comment:
I'm seeing this on a rebuild now of Python 3.7.4 on Ubuntu 18.04 (in my case
against _ssl.c).
What's happening is there's coverage/profiling data being generated in the
build chain (somewhere), which spits out files named *.gcda. Interestingly,
make clean does *not* clean these files up.
gcc is attempting to use this data in its optimization, but discovers that it's
now bogus -- likely due to system library headers (like OpenSSL) being updated
in the meantime, with some inline code causing the coverage data to become
invalid.
The fix should be to have 'make clean' clean up these *.gcda files. In the
meantime, the workaround is to run "find . -name \*.gcda -exec rm '{}' \;"
--
nosy: +dacut
versions: +Python 3.7 -Python 3.8
___
Python tracker
<https://bugs.python.org/issue34820>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34820] binascii.c:1578:1: error: the control flow of function ‘binascii_crc32’ does not match its profile data (counter ‘arcs’)
Change by David Cuthbert : -- versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue34820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port
David Cuthbert added the comment: How much harm would there be in bringing the DeprecationWarning into the next patch of existing (3.6, 3.7, 3.8) releases? The security implications are significant enough that I'd want to be notified of it in my software ASAP. Users can (and should!) squelch the warning by passing the setting explicitly. -- nosy: +dacut ___ Python tracker <https://bugs.python.org/issue37228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port
David Cuthbert added the comment: I'm working on patches for the deprecation bits (targeting 3.6 for now; will work my way up from there) for review, including documentation. Unless someone tells me to stop. :-) In an attempt to make this not-so-Linux-specific, I'm reviewing how this works on non-Linux platforms (MacOS, FreeBSD) as well. Reading Linux's socket(7) man page makes it seem like reuse_port is the issue (but that actually has protections to ensure you're only doing it across the same UID at least). I had to write my own test jig to (re-)convince myself that, indeed, reuse_addr is the problem. -- ___ Python tracker <https://bugs.python.org/issue37228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port
David Cuthbert added the comment: FreeBSD 12.1 and MacOS 10.15.1 (Catalina) appear to have saner and safer behavior. Both require the use of SO_REUSEPORT for this behavior to happen as well. FreeBSD also requires the UID to be the same or 0 for subsequent processes to make the bind() call. I'll call this out as being Linux-specific in the deprecation message for now. (I don't have an AIX, HP-UX, or Solaris system handy to test, nor do I really want one if I'm being honest. :-) .) -- ___ Python tracker <https://bugs.python.org/issue37228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port
David Cuthbert added the comment: Alright -- my first stab at the DeprecationWarning in 3.6. https://github.com/dacut/cpython/commit/6a1e261678975e2c70ec6b5e98e8affa28702312 Please critique away, and don't fret about bruising my ego. :-) Is there a more idiomatic way of getting a warning to show up against the first callee that's not in the current module? I'm not enamored of the monstrosity I'm put together around line 918 of base_events.py (but less enamored about displaying warnings that the user is going to tear their hair out over trying to find the offending source line): https://github.com/dacut/cpython/commit/6a1e261678975e2c70ec6b5e98e8affa28702312#diff-08afa52ab2b1511bee8527814ad44d80R918 -- ___ Python tracker <https://bugs.python.org/issue37228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port
David Cuthbert added the comment: Jukka -- Fair enough; will reword this a bit. I'm trying to keep the DeprecationWarning short enough so people's eyes don't glaze over; will see what wordsmithing I can do here. (Once you get beyond a certain length, the number of folks who actually read the message goes down the longer it is.) -- ___ Python tracker <https://bugs.python.org/issue37228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port
David Cuthbert added the comment: On the completely deprecate reuse_address and rewrite/force folks to use reuse_port proposals, I'm a bit dubious of this approach. Right now, we have two knobs that directly correspond to (potential) kernel-level socket parameters, SO_REUSEADDR and SO_REUSEPORT. We just chose an unfortunate default for one of them. Otherwise, the behavior is nicely explicit. Rewriting or forbidding it, even when the user has (essentially) acknowledged they're accepting risks by passing reuse_address=True, seems to fly in the face of this. Users get bitten when we start convoluting logic here (I was just bitten by fcntl.lockf() not actually calling lockf() last month and ended up having to call lockf() via ctypes.). There are some platforms (Linux pre-3.9 kernels) that don't have SO_REUSEPORT. I wish I could say I don't care about such platforms; alas, I just had to compile Python 3.7 on a system running a 2.6 kernel last month at a client site. Finally, I've only scratched the surface with my test cases, on single-homed systems, IPv4, and binding to 0.0.0.0. There are a lot of parameters to try here before we decree that reuse_address has no purpose existing, and an OS could later reimplement saner defaults on SO_REUSEADDR. Changing a default already has some controversy (Yury was -1 on this change). This seems much bigger and I'm not convinced we fully understand its ramifications. That said, I'll happily implement whatever the consensus ends up being, or consensus as designated by the vBDFL, or wherever that decision needs to come from. :-) -- ___ Python tracker <https://bugs.python.org/issue37228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32117] Tuple unpacking in return and yield statements
New submission from David Cuthbert : This stems from a query on StackOverflow: https://stackoverflow.com/questions/47272460/python-tuple-unpacking-in-return-statement/ Specifically, the following syntax is allowed: def f(): rest = (4, 5, 6) t = 1, 2, 3, *rest While the following result in SyntaxError: def g(): rest = (4, 5, 6) return 1, 2, 3, *rest def h(): rest = (4, 5, 6) yield 1, 2, 3, *rest Looking at the original commit that enabled tuple unpacking in assignment statements: https://github.com/python/cpython/commit/4905e80c3d2f6abb613d212f0313d1dfe09475dc I don't believe this difference is intentional. My GitHub repo incorporates a fix for this; I'll file a pull request momentarily. -- components: Interpreter Core messages: 306761 nosy: dacut priority: normal severity: normal status: open title: Tuple unpacking in return and yield statements type: behavior versions: Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue32117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32117] Tuple unpacking in return and yield statements
Change by David Cuthbert : -- keywords: +patch pull_requests: +4446 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32117] Tuple unpacking in return and yield statements
David Cuthbert added the comment: CLA processed, and BDFL has assented on python-dev. Serhiy, thoughts on next steps? -- ___ Python tracker <https://bugs.python.org/issue32117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32117] Tuple unpacking in return and yield statements
David Cuthbert added the comment: Hm... that leaves the only production for expression_list as: subscription ::= primary "[" expression_list "]" And I'm not sure that this shouldn't also be replaced by starred_list. It's not accepted today, though: In [6]: a[1,*(4, 5, 6)] File "", line 1 a[1,*(4, 5, 6)] ^ SyntaxError: invalid syntax I will ask about this again on python-dev@ -- ___ Python tracker <https://bugs.python.org/issue32117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32117] Tuple unpacking in return and yield statements
David Cuthbert added the comment: Oops, I wasn't looking broadly enough. This is also used in the augmented assignment statements syntax, e.g. a += 1, 2, 3 -- ___ Python tracker <https://bugs.python.org/issue32117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
