From report at bugs.python.org Wed Feb 1 02:02:05 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 01 Feb 2017 07:02:05 +0000 Subject: [New-bugs-announce] [issue29410] Moving to SipHash-1-3 Message-ID: <1485932525.38.0.562666093651.issue29410@psf.upfronthosting.co.za> New submission from INADA Naoki: Rust and Ruby moved from SipHash-2-4 to SipHash-1-3. https://github.com/rust-lang/rust/issues/29754 https://bugs.ruby-lang.org/issues/13017 SipHash-1-3 seems faster than 2-4 and secure enough. ---------- messages: 286590 nosy: inada.naoki priority: normal severity: normal status: open title: Moving to SipHash-1-3 versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 05:43:53 2017 From: report at bugs.python.org (Michal Cyprian) Date: Wed, 01 Feb 2017 10:43:53 +0000 Subject: [New-bugs-announce] [issue29411] Option --executable for entry_points Message-ID: <1485945833.17.0.354426636585.issue29411@psf.upfronthosting.co.za> New submission from Michal Cyprian: 1. python3 setup.py build --executable="/usr/bin/binary" 2. python3 setup.py install -O1 --skip-build These two commands are typically used to build and install Python packages from sources. Let's assume there is a setup.py script of package foo, containing a script foo. The --executable option of build command (1) should set the shebang of the script foo to #!/usr/bin/binary. The problem is that this option doesn't work for scripts listed in setup.py as entry_points, which is the most common way of handling scripts these days. The idea of the original design was probably to pass the value of --executable to the build_scripts command and set shebang there. However, this command is not executed if the package contains only entry_points. The scripts listed as entry_points are processed during execution of the install command (2) (specifically, in the easy_install command), which is completely isolated from the build command (1) and doesn't have access to the value specified in the --executable option. The only reasonable solution that came to my mind was to add the --executable option to the install command as well, pass it to the easy_install command and make the ScriptWriter class use this value. I prepared a patch that fixes this issue in setuptools [1]. To make it work, a small patch [2] will have to be applied to distutils as well. Would this or something similar be acceptable for distutils? I've already sent this proposal to pypa-dev mailing list, they replied that patch will be useful. The patch [2] needs to go to distutils first, to make patch for setuptools work. [1] https://github.com/mcyprian/python-setuptools/blob/system-python/add-executable-option.patch [2] https://github.com/mcyprian/python-setuptools/blob/system-python/add-executable-option.patch ---------- components: Distutils messages: 286612 nosy: Michal Cyprian, dstufft, eric.araujo priority: normal severity: normal status: open title: Option --executable for entry_points type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 08:53:21 2017 From: report at bugs.python.org (Joel Uckelman) Date: Wed, 01 Feb 2017 13:53:21 +0000 Subject: [New-bugs-announce] [issue29412] IndexError thrown on email.message.M Message-ID: <1485957201.62.0.708721670813.issue29412@psf.upfronthosting.co.za> New submission from Joel Uckelman: Test case: import email import email.policy txt = '''From: juckelman at strozfriedberg.co.uk To: (Recipient list suppressed) Date: Thu, 22 Aug 2013 04:13:02 +0000 Subject: ADSF-1082 Hey! ''' msg = email.message_from_string(txt) msg.get('to') msg = email.message_from_string(txt, policy=email.policy.default) msg.get('to') The second msg.get() throws an IndexError: Traceback (most recent call last): File "test.py", line 16, in print(msg.get('to')) # throws IndexError File "/usr/lib64/python3.5/email/message.py", line 472, in get return self.policy.header_fetch_parse(k, v) File "/usr/lib64/python3.5/email/policy.py", line 153, in header_fetch_parse return self.header_factory(name, ''.join(value.splitlines())) File "/usr/lib64/python3.5/email/headerregistry.py", line 586, in __call__ return self[name](name, value) File "/usr/lib64/python3.5/email/headerregistry.py", line 197, in __new__ cls.parse(value, kwds) File "/usr/lib64/python3.5/email/headerregistry.py", line 337, in parse kwds['parse_tree'] = address_list = cls.value_parser(value) File "/usr/lib64/python3.5/email/headerregistry.py", line 328, in value_parser address_list, value = parser.get_address_list(value) File "/usr/lib64/python3.5/email/_header_value_parser.py", line 2336, in get_address_list token, value = get_address(value) File "/usr/lib64/python3.5/email/_header_value_parser.py", line 2313, in get_address token, value = get_group(value) File "/usr/lib64/python3.5/email/_header_value_parser.py", line 2269, in get_group token, value = get_display_name(value) File "/usr/lib64/python3.5/email/_header_value_parser.py", line 2095, in get_display_name token, value = get_phrase(value) File "/usr/lib64/python3.5/email/_header_value_parser.py", line 1770, in get_phrase token, value = get_word(value) File "/usr/lib64/python3.5/email/_header_value_parser.py", line 1745, in get_word if value[0]=='"': IndexError: string index out of range The docs say that email.policy.default has raise_on_defect set to False, hence parse errors ought to be reported via EmailMessage.defects, not by throwing an exception. ---------- components: email messages: 286631 nosy: barry, r.david.murray, uckelman priority: normal severity: normal status: open title: IndexError thrown on email.message.M type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:05:31 2017 From: report at bugs.python.org (Greg Stark) Date: Wed, 01 Feb 2017 19:05:31 +0000 Subject: [New-bugs-announce] [issue29413] ssl.SSLSocket.unwrap() is not flexible enough Message-ID: <1485975931.82.0.260230728322.issue29413@psf.upfronthosting.co.za> New submission from Greg Stark: This is not a bug, but rather a request for API improvements. Correct SSL shutdown processing is frequent source of confusion. Python?s ssl module unfortunately lacks the flexibility to accommodate some common paradigms. The problem is that the unwrap() method of SSLObject and SSLSocket always blocks until it receives the peer?s close_notify alert. This is the sensible default since it is the most secure. However, it is also common (and secure) to send the close_notify and then shutdown the socket immediately after without waiting for the peer?s close_notify alert. More details can be found in section 7.2.1 of RFC 2246 and its successors. Another good source is the discussion at http://security.stackexchange.com/questions/82028/ssl-tls-is-a-server-always-required-to-respond-to-a-close-notify To accommodate the range of SSL shutdown behaviors in the real world I propose two small API changes. One is to add a keyword argument to the unwrap() method of SSLSocket and SSLObject. The new keyword argument is wait_for_peer, and it?s default value should be True. unwrap(wait_for_peer=True) would be the default behavior, and would match the current behavior: always wait for the peer to send the close_notify. unwrap(wait_for_peer=False) however, would return successfully after sending the close_notify whether or not the peer has sent their close_notify. In addition, a new method ?get_shutdown_state()? is needed to retrieve the current shutdown state of the SSL connection or object. Or perhaps the method could be a simple boolean ?has_peer_sent_shutdown()?. This is just one proposal for adding some necessary flexibility with minimal API changes. Other approaches are possible. ---------- assignee: christian.heimes components: SSL messages: 286674 nosy: Greg Stark, christian.heimes priority: normal severity: normal status: open title: ssl.SSLSocket.unwrap() is not flexible enough type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 14:10:16 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Wed, 01 Feb 2017 19:10:16 +0000 Subject: [New-bugs-announce] [issue29414] Change 'the for statement is such an iterator' in Tutorial Message-ID: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za> New submission from Jim Fasarakis-Hilliard: The current line is confusing hinting that the for statement is actually an object, it also makes a reference to iterators which the tutorial doesn't disambiguate until the chapter on Classes. I've added a small patch that, in my opinion, makes it clearer by using the terminology of the previous sentence. ---------- assignee: docs at python components: Documentation messages: 286678 nosy: Jim Fasarakis-Hilliard, docs at python priority: normal severity: normal status: open title: Change 'the for statement is such an iterator' in Tutorial versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 16:51:35 2017 From: report at bugs.python.org (Max) Date: Wed, 01 Feb 2017 21:51:35 +0000 Subject: [New-bugs-announce] [issue29415] Exposing handle._callback and handle._args in asyncio Message-ID: <1485985895.46.0.167923746012.issue29415@psf.upfronthosting.co.za> New submission from Max: Is it safe to use the _callback and _args attributes of asyncio.Handle? Is it possible to officially expose them as public API? My use case: handle = event_loop.call_later(delay, callback) # this function can be triggered by some events def reschedule(handle): event_loop.call_later(new_delay, handle._callback, *handle._args) handle.cancel() ---------- components: asyncio messages: 286709 nosy: gvanrossum, max, yselivanov priority: normal severity: normal status: open title: Exposing handle._callback and handle._args in asyncio type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 17:46:32 2017 From: report at bugs.python.org (Dan Buchoff) Date: Wed, 01 Feb 2017 22:46:32 +0000 Subject: [New-bugs-announce] [issue29416] Path.mkdir can get into a recursive error loop Message-ID: <1485989192.98.0.740495069051.issue29416@psf.upfronthosting.co.za> New submission from Dan Buchoff: If a path has a non-existent anchor, Path.mkdir can get into a RecursionError as it tries to recursively create the parent. I expect a more sane error. This is readily reproducible in Windows with `Path('Z:').mkdir(parents=True)` Example execution: Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from pathlib import Path >>> Path('Z:').mkdir(parents=True) Traceback (most recent call last): File "C:\Python36\lib\pathlib.py", line 1231, in mkdir self._accessor.mkdir(self, mode) File "C:\Python36\lib\pathlib.py", line 388, in wrapped return strfunc(str(pathobj), *args) FileNotFoundError: [WinError 3] The system cannot find the path specified: 'Z:' During handling of the above exception, another exception occurred: ... During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "C:\Python36\lib\pathlib.py", line 1238, in mkdir self.parent.mkdir(parents=True) File "C:\Python36\lib\pathlib.py", line 1238, in mkdir self.parent.mkdir(parents=True) File "C:\Python36\lib\pathlib.py", line 1238, in mkdir self.parent.mkdir(parents=True) [Previous line repeated 989 more times] File "C:\Python36\lib\pathlib.py", line 1231, in mkdir self._accessor.mkdir(self, mode) File "C:\Python36\lib\pathlib.py", line 388, in wrapped return strfunc(str(pathobj), *args) RecursionError: maximum recursion depth exceeded ---------- components: Library (Lib), Windows messages: 286717 nosy: Dan Buchoff, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Path.mkdir can get into a recursive error loop versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 1 20:18:06 2017 From: report at bugs.python.org (Douglas Greiman) Date: Thu, 02 Feb 2017 01:18:06 +0000 Subject: [New-bugs-announce] [issue29417] Sort entries in foo.dist-info/RECORD Message-ID: <1485998286.97.0.0656038336058.issue29417@psf.upfronthosting.co.za> New submission from Douglas Greiman: Feature Request: It would make reproducible builds easier if the [package].dist-info/RECORD files were sorted in some deterministic way. For example, building a Docker image twice and comparing the results. The current ordering seems to be arbitrary, and I didn't find any PEPs that specify one way or the other. I'm not sure what would need to be updated for this change. The whole pip/distutils/setuptools ecosystem is a bit murky. ---------- components: Distutils messages: 286729 nosy: dgreiman, dstufft, eric.araujo priority: normal severity: normal status: open title: Sort entries in foo.dist-info/RECORD type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 04:32:53 2017 From: report at bugs.python.org (Manuel Krebber) Date: Thu, 02 Feb 2017 09:32:53 +0000 Subject: [New-bugs-announce] [issue29418] inspect.isroutine does not return True for some bound builtin methods Message-ID: <1486027973.42.0.383629669841.issue29418@psf.upfronthosting.co.za> New submission from Manuel Krebber: Some of the builtin methods are not recognized as such by inspect.isroutine(). inspect.ismethoddescriptor() only returns True for the unbound versions of the methods but not the bound ones. For example: >>> inspect.isroutine(object.__str__) True >>> inspect.isroutine(object().__str__) False The second one should also return True as it does for user-defined classes: >>> class A: ... def f(self): ... pass >>> inspect.isroutine(A.f) True >>> inspect.isroutine(A().f) True The types needed for that have already been added to the types module in issue #29377. Here is the commit: https://github.com/python/cpython/commit/1947d33a0a1c2ba006397579ec6235528faea9fd ---------- components: Library (Lib) messages: 286752 nosy: Wheerd, levkivskyi, yselivanov priority: normal severity: normal status: open title: inspect.isroutine does not return True for some bound builtin methods type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 07:50:49 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Feb 2017 12:50:49 +0000 Subject: [New-bugs-announce] [issue29419] Argument Clinic: inline PyArg_UnpackTuple and PyArg_ParseStack(AndKeyword)? Message-ID: <1486039849.42.0.101303637281.issue29419@psf.upfronthosting.co.za> New submission from STINNER Victor: Argument Clinic calls one the following functions depending on parameters: * PyArg_UnpackTuple(), _PyArg_UnpackStack() * PyArg_ParseTuple(), _PyArg_ParseStack() * PyArg_ParseTupleAndKeywords(), _PyArg_ParseStackAndKeywords() * etc. Would it make sense to emit C code instead of calling complex and slow PyArg_ParseXXX() functions? It would emit the most efficient C code to parse arguments. I don't recall where this idea comes from. Maybe Larry Hastings told me once that he wants to implement this idea :-) I'm sure that Larry has a big plan but lacks time to implement all of his cool ideas. Using profiled guided optimization (PGO), the compiler should be able to easily detect that error cases are unlikely and mark these code paths as unlikely. We should probably experiment an implementation to be able to measure the speedup, to be able to say if the idea is worth it or not, in term of performance, since the motivation here is clearly performance. We can begin with format strings only made of "O" format. Most simple example with divmod(), replace: if (!_PyArg_UnpackStack(args, nargs, "divmod", 2, 2, &x, &y)) { return NULL; } with something like: if (nargs != 2) { _PyArg_ErrNumArgs(nargs, 2, 2, "divmod"); return NULL; } x = args[0]; y = args[1]; The next question is if we should go further with more complex formats. Example with the format() function, replace: if (!_PyArg_ParseStack(args, nargs, "O|U:format", &value, &format_spec)) { ... } with: if (nargs < 1 || nargs > 2) { _PyArg_ErrNumArgs(nargs, 1, 2, "format"); return NULL; } value = args[0]; if (nargs == 2) { format_spec = args[1]; if (!PyUnicode_Check(format_spec)) { .. raise an exception ...; return NULL; } /* getargs.c calls PyUnicode_READY(), we should also do it here */ if (PyUnicode_READY(format_spec) == -1) { return NULL; } } else { format_spec = NULL; } ---------- components: Argument Clinic messages: 286778 nosy: haypo, inada.naoki, larry, serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic: inline PyArg_UnpackTuple and PyArg_ParseStack(AndKeyword)? type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:10:45 2017 From: report at bugs.python.org (Matthew Brett) Date: Thu, 02 Feb 2017 14:10:45 +0000 Subject: [New-bugs-announce] [issue29420] Python 3.6 change in dict iteration when inserting keys Message-ID: <1486044645.48.0.643305374135.issue29420@psf.upfronthosting.co.za> New submission from Matthew Brett: The behavior of dict iteration has changed in Python 3.6, in that inserting keys during iteration has a different and unpredictable affect. For this code: d = {'foo': 1} for key in d: print(key) d.pop(key) d[key] = 1 Python 3.5 prints a single 'foo' (one pass through the loop). Python 3.6 generates five lines of 'foo' (five passes through the loop). Of course this code is pathological, but I found this behavior from a bug in code where the pathology was a lot less obvious - see https://github.com/nipy/nipy/issues/420 ---------- messages: 286794 nosy: matthew.brett priority: normal severity: normal status: open title: Python 3.6 change in dict iteration when inserting keys type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 09:31:54 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Feb 2017 14:31:54 +0000 Subject: [New-bugs-announce] [issue29421] Make int.to_bytes() and int.from_bytes() slightly faster Message-ID: <1486045914.4.0.194777951008.issue29421@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes int.to_bytes() and int.from_bytes() slightly faster. $ ./python -m perf timeit '1 .to_bytes(4, "little")' --compare-to "`pwd`/python0" Median +- std dev: [python0] 1.28 us +- 0.07 us -> [python] 1.17 us +- 0.07 us: 1.09x faster (-8%) $ ./python -m perf timeit '1 .to_bytes(4, "big")' --compare-to "`pwd`/python0" Median +- std dev: [python0] 1.30 us +- 0.07 us -> [python] 1.19 us +- 0.05 us: 1.10x faster (-9%) $ ./python -m perf timeit 'int.from_bytes(b"\1\0\0\0", "little")' --compare-to "`pwd`/python0" Median +- std dev: [python0] 1.70 us +- 0.13 us -> [python] 1.41 us +- 0.06 us: 1.20x faster (-17%) $ ./python -m perf timeit 'int.from_bytes(b"\0\0\0\1", "big")' --compare-to "`pwd`/python0" Median +- std dev: [python0] 1.71 us +- 0.15 us -> [python] 1.40 us +- 0.05 us: 1.22x faster (-18%) ---------- components: Interpreter Core files: int-to_bytes-from_bytes.patch keywords: patch messages: 286796 nosy: haypo, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Make int.to_bytes() and int.from_bytes() slightly faster type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46491/int-to_bytes-from_bytes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 11:51:34 2017 From: report at bugs.python.org (Patrick Michaud) Date: Thu, 02 Feb 2017 16:51:34 +0000 Subject: [New-bugs-announce] [issue29422] add socket independent timeout to httplib/http.client read Message-ID: <1486054294.14.0.838994744532.issue29422@psf.upfronthosting.co.za> New submission from Patrick Michaud: Using python's httplib, there is no way to set a timeout for the full request cycle. A timeout can be given, which will apply to the connection attempt and each blocking socket operation. However, a malicious (or poorly performing) server can keep a connection open for an indefinite amount of time by slowly sending data. Consider this server process: https://gist.github.com/vegitron/bc883ddc88fe9253adc3e0bccea6445e and this client: https://gist.github.com/vegitron/4ee269b6492ff80d350e108363689d5c With a timeout of 0.5, the client takes 0.501363039017 seconds. With a timeout of 2.5, it takes 10.0041370392 seconds. This is explained in the documentation, but it's a problem. A commonly suggested solution is to use SIGALRM to set a timeout, but that doesn't work in a multi-threaded environment. Moving to multi-process introduces big slow downs as I can't use connection pools, and data needs to be serialized and deserialized for the parent process. I would like to propose an addition to httplib that would add a hook to httplib.HTTPResponse._read_chunked (python 2) and http.client.HTTPResponse._readall_chunked (python 3) that would either: 1) support an overall read timeout, by tracking a per-response start time and raising a timeout exception if that chunk read finishes after the given timeout 2) support a per-chunk callback function, so a client of httplib/http.client could define that logic for themselves. Current possible timeouts, and where they can happen: connect | read chunk | read chunk | read chunk [ timeout ] [ timeout ] [ timeout ] [ timeout ] Proposed addition: connect | read chunk | read chunk | read chunk [ timeout ] [ timeout ] [ timeout ] [ timeout ] [ total read time out ] ---------- messages: 286807 nosy: Patrick Michaud priority: normal severity: normal status: open title: add socket independent timeout to httplib/http.client read type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 16:00:20 2017 From: report at bugs.python.org (spencera) Date: Thu, 02 Feb 2017 21:00:20 +0000 Subject: [New-bugs-announce] [issue29423] using concurrent.futures.ProcessPoolExecutor in class giving 'TypeError: can't pickle _thread.RLock objects' in 3.6, but not 3.5 Message-ID: <1486069220.1.0.0155992430092.issue29423@psf.upfronthosting.co.za> New submission from spencera: I'm unable to use concurrent.futures.ProcessPoolExecutor within a class in 3.6 the way I can in 3.5.x. I get the following in 3.6 (python3.6 test.py): Traceback (most recent call last): File "/usr/local/lib/python3.6/multiprocessing/queues.py", line 241, in _feed obj = _ForkingPickler.dumps(obj) File "/usr/local/lib/python3.6/multiprocessing/reduction.py", line 51, in dumps cls(buf, protocol).dump(obj) TypeError: can't pickle _thread.RLock objects --------------------- No issues in 3.5.x: 0 1 2 3 4 5 6 7 8 9 0 ... ---------- components: Library (Lib) files: test.py messages: 286825 nosy: spencera priority: normal severity: normal status: open title: using concurrent.futures.ProcessPoolExecutor in class giving 'TypeError: can't pickle _thread.RLock objects' in 3.6, but not 3.5 type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46496/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 16:33:01 2017 From: report at bugs.python.org (Meitar Moscovitz) Date: Thu, 02 Feb 2017 21:33:01 +0000 Subject: [New-bugs-announce] [issue29424] Multiple vulnerabilities in BaseHTTPRequestHandler enable HTTP response splitting attacks Message-ID: <1486071181.22.0.61090318362.issue29424@psf.upfronthosting.co.za> New submission from Meitar Moscovitz: SUMMARY: In the Python standard library, the BaseHTTPRequestHandler class?s send_header() method[0] does not correctly construct HTTP/1.1 message headers as described by Section 4.2 of RFC 2616[1] when it is given maliciously-crafted input, leaving applications that rely on it vulnerable to HTTP response splitting[2] if they do not take extra precautions, themselves. A similar vulnerability affects the BaseHTTPRequestHandler class?s send_response_only() method, as well, although this is not likely to be as exploitable in the wild. This second vulnerability can result in HTTP response splitting due to incorrect construction of the Reason-Phrase portion of an HTTP Status-Line.[3] Since these APIs are designed to handle user-supplied input, it is reasonable to assume that developers will expect the standard library to consume arbitrary input safely. Unfortunately, the library fails to do that in these cases. According to a simple GitHub code search, slightly more than 100,000 repositories are directly using BaseHTTPRequestHandler,[4] so it is possible that a significant percentage of those applications are affected by this vulnerability. PYTHON VERSIONS AFFECTED: * Current development tip at time of writing: https://hg.python.org/cpython/file/tip/Lib/http/server.py#l511 * Current stable version 3.6 release (https://hg.python.org/cpython/file/3.6/Lib/http/server.py#l508) * Current stable version 2.7.13 release (https://hg.python.org/cpython/file/2.7/Lib/BaseHTTPServer.py#l412) DETAILS: According to the HTTP specification, an HTTP message header field content *MUST NOT* contain the sequence CRLF (carriage return, line feed). The RFC defines a message header as: message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = The RFC defines *TEXT to be the same as defined in RFC 822 section 3.3:[5] text = atoms, specials, CR & bare LF, but NOT ; comments and including CRLF> ; quoted-strings are ; NOT recognized. However, the send_header() method does not perform any checking to ensure that a message header field-name nor field-content contains no CRLF sequences. The vulnerable Python 3.x code is in Lib/http/server.py on lines 507 and 508: self._headers_buffer.append( ("%s: %s\r\n" % (keyword, value)).encode('latin-1', 'strict')) An impacted application is one that passes user-provided input into the send_header() method, such as is common for setting HTTP Cookies. An example of an affected application may run Python code such as: def do_POST(self): # receive user-supplied data from a POST?ed HTTP request form_input = parse.unquote_plus( self.rfile.read(int(self.headers.get('content-length'))).decode('utf8') ).split('=') username = form_input[1] # extract a user-supplied value self.send_header('Set-Cookie', 'user={}'.format(username)) # use that value, assuming library will provide safety! self.end_headers() # ... send HTTP response body ... Assuming the code above, this HTTP POST request? POST https://victim.example/ HTTP/1.1 Host: victim.example Content-Type: application/x-www-form-urlencoded Content-Length: 10 user=alice ?would produce something like this (safe) HTTP response: HTTP/1.0 200 OK Server: BaseHTTP/0.6 Python/3.4.5 Date: Thu, 19 Jan 2017 22:58:44 GMT Set-Cookie: user=alice ...HTTP RESPONSE BODY... However, if an attacker supplies the following, maliciously-crafted HTTP POST payload? POST https://victim.example/ HTTP/1.1 Host: victim.example Content-Type: application/x-www-form-urlencoded Content-Length: 46 user=%0d%0aContent-Length: 6%0d%0a%0d%0aHACKED ?then the application would serve a page that simply read ?HACKED? as its output: HTTP/1.0 200 OK Server: BaseHTTP/0.6 Python/3.4.5 Date: Thu, 19 Jan 2017 22:58:44 GMT Set-Cookie: user= Content-Length: 6 HACKED The remainder of the application?s original, intended HTTP response would be ignored by the client. This allows the attacker to submit arbitrary data to clients, including hijacking complete pages and executing XSS attacks. SOLUTION: To fix this issue, ensure that CRLF sequences in the relevant user-supplied values are replaced with a single SPACE character, as the RFC instructs.[1] For example, Python code referencing value should become value.replace("\r\n", ' ') Similar replacements should be made to the other relevant arguments in the affected methods. Two patches are attached to this email, one for each associated affected version of Python. Apply each patch with: cd Python-$VERSION patch -p1 < python-$VERSION.patch where $VERSION is the version of Python to be patched. The patch for Python 3.6.0 applies cleanly to the current development tip, as well. EXTERNAL REFERENCES: [0] https://hg.python.org/cpython/file/3.6/Lib/http/server.py#l502 [1] https://tools.ietf.org/html/rfc2616#section-4.2 [2] https://www.owasp.org/index.php/HTTP_Response_Splitting [3] https://tools.ietf.org/html/rfc2616#section-6.1 [4] https://github.com/search?q=BaseHTTPRequestHandler+language%3Apython&type=Code [5] https://tools.ietf.org/html/rfc822#section-3.3 SEE ALSO: https://bugs.python.org/issue17319 P.S. This is my first time reporting a bug to the Python Software Foundation. I can prioritize improving this report with feedback from you if you need any clarifications or further details. ---------- components: Library (Lib) files: python-3.6.0.patch keywords: patch messages: 286828 nosy: meitar priority: normal severity: normal status: open title: Multiple vulnerabilities in BaseHTTPRequestHandler enable HTTP response splitting attacks type: security versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46497/python-3.6.0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 19:04:13 2017 From: report at bugs.python.org (Walter Szeliga) Date: Fri, 03 Feb 2017 00:04:13 +0000 Subject: [New-bugs-announce] [issue29425] File-altering aspects of pathlib should return new pathlib objects Message-ID: <1486080253.05.0.537199940287.issue29425@psf.upfronthosting.co.za> New submission from Walter Szeliga: Methods on pathlib.PosixPath() and other objects that alter files on the file system should return new object instances with new information. For example, if there exists a file on the system called 'bar', then bar_var = pathlib.PosixPath('bar') bar_var.rename('foo') will rename the file 'bar' to 'foo' on the system and leave 'bar' as a still-valid object that no longer points to a system file. Changing the return type of .rename() to return a new pathlib.PosixPath() object with path 'foo' could help reduce confusion about the behavior. For example: bar_var = pathlib.PosixPath('bar') foo_var = bar_var.rename('foo') and foo_var would then be a pathlib.PosixPath() object pointing to 'foo'. ---------- components: Library (Lib) messages: 286835 nosy: Walter Szeliga priority: normal severity: normal status: open title: File-altering aspects of pathlib should return new pathlib objects type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 19:14:13 2017 From: report at bugs.python.org (Mark Tischler) Date: Fri, 03 Feb 2017 00:14:13 +0000 Subject: [New-bugs-announce] [issue29426] Using pywin32 on Python3 on linux Message-ID: <1486080853.04.0.234101899085.issue29426@psf.upfronthosting.co.za> New submission from Mark Tischler: I downloaded pywin32 build 220 from https://sourceforge.net/projects/pywin32/files/pywin32/, and tried to install it using 'python3 setup.py install' as well as 'python3 pywin32_postinstall.py -install' ("python3" = python 3.6.0), and the former gave me a syntax error about 'print' needing parentheses, and the latter gave me a syntax error about an 'except' statement having a syntax error, both of which tell me that this pywin32 package is not compatible with Python 3. So, I went searching and found https://pypi.python.org/pypi/pypiwin32. This is the same build number -- 220. Given that it is a full year newer than the other (it's odd that its build number is the same), I thought that this might have changes in it to support Python3. However, given that I'm installing on a Linux platform, I don't think I can deal with wheel files. These downloadable files appear to be for Windows installations only. I'm attempting to have an app, which is installed on a RedHat Linux machine, use SQL Server as its database, so my understanding is that I need the django-mssql package (I have version 1.8 ready to go) and that is dependent upon pywin32. So, I'm wondering if there is a version of pywin32 that is compatible with Python 3.6.0 and that is installable on Red Hat Linux. I am not using 'pip' to install packages, because my installation is not in the normal system area. I have a library of multiple Python installations, so that the various apps installed on that machine can be pointed to one of several different versions of Python. Note, I am somewhat new to Python and Python installations. Any help would be appreciated. ---------- components: Installation messages: 286836 nosy: mtischler priority: normal severity: normal status: open title: Using pywin32 on Python3 on linux type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 2 20:25:17 2017 From: report at bugs.python.org (Brian Thorne) Date: Fri, 03 Feb 2017 01:25:17 +0000 Subject: [New-bugs-announce] [issue29427] Option to skip padding for base64 urlsafe encoding/decoding Message-ID: <1486085117.43.0.563120448637.issue29427@psf.upfronthosting.co.za> New submission from Brian Thorne: Suggest changing base64 module to better handle encoding schemes that don't use padding. Because RFC4648 [1] allows other RFCs that implement RFC4648-compliant base64url encoding to explicitly stipulate that there is no padding. Dropping the padding is lossless when we know the length [2]. Various standard specifications require this - often crypto related (e.g., JWS [3] or named hashes [4]). RFC4648 specifically makes an exemption for this and it should be better supported in Python's standard library. There is a related closed issue [5] asking for the padding to be removed or altered which wouldn't comply with the spec. This request is different with a view to better support the wider specification. Proposed behaviour adapted from resolution that ruby discussion on same topic [6]: - base64.urlsafe_b64encode(s) should continue to produce padded output, but have an additional argument, padding, which defaults to True. - base64.urlsafe_b64decode(s) should accept both padded and unpadded inputs. It can still reject incorrectly-padded input. If that sounds sensible I'd like to put a patch/PR together. >From wikipedia [7]: > Some variants allow or require omitting the padding '=' signs to avoid them being confused with field separators, or require that any such padding be percent-encoded. Some libraries will encode '=' to '.'. - [1] https://tools.ietf.org/html/rfc4648#page-4 - [2] http://stackoverflow.com/questions/4080988/why-does-base64-encoding-requires-padding-if-the-input-length-is-not-divisible-b - [3] https://tools.ietf.org/html/rfc7515 - [4] https://tools.ietf.org/html/rfc6920#section-3 - [5] http://bugs.python.org/issue1661108 - [6] https://bugs.ruby-lang.org/issues/10740 - [7] https://en.wikipedia.org/wiki/Base64#Output_Padding ---------- components: Library (Lib) messages: 286837 nosy: Thorney, georg.brandl, lemburg, loewis priority: normal severity: normal status: open title: Option to skip padding for base64 urlsafe encoding/decoding type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 01:25:12 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Fri, 03 Feb 2017 06:25:12 +0000 Subject: [New-bugs-announce] [issue29428] Doctest documentation unclear about multi-line fixtures Message-ID: <1486103112.9.0.326343032946.issue29428@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: I just had a problem with doctests. It manifested as an error that occurred when I did >>> import StringIO in my doctest. After some investigation, I realised that my actual problem was that the doctest library documentation https://docs.python.org/3/library/doctest.html left me unclear about three aspects of multi-line doctest fixtures. 1. There is no example of a multiple-line doctest fixture: specifically, a fixture which involves at least one line to set up state, and another line to be the example that tested. I suggest adding such an example as a new section, "26.3.2. Usage: multi-line tests". Note that the example in 26.3.3.2 doesn't count: that is a Compound Statement, and I'm talking about a test consisting of multiple interactive statements. 2. Section "26.3.3.2. How are Docstring Examples Recognized?" does not talk about when to use a PS1 prefix (>>>) and when to use a PS2 prefix (...). It should say to use the PS1 at the start of each Python "interactive statement", that is, a statement list ending with a newline, or a Compound Statement. And, to use the PS2 to prefix each continuing line within a Compound Statement. 3. Section "26.3.3.3. What?s the Execution Context?" is not clear about the crucial difference between state that accumulates within a single docstring from Example to Example, and that is reset from one docstring to another. The phrase "so that one test in M can?t leave behind crumbs that accidentally allow another test to work" can be interpreted as applying within a single docstring. The phrase "names defined earlier in the docstring being run" is easy to miss. A StackOverflow Question and Answer describing my problem and my insight about what the library documentation didn't tell me is at http://stackoverflow.com/questions/41070547/why-is-importing-a-module-breaking-my-doctest-python-2-7 . A blog post of mine, a source for documentation improvements, is at http://blog.jdlh.com/en/2017/01/31/multi-line-doctests/ . I actually encountered this problem in a Python 2.7 context, with https://docs.python.org/2/library/doctest.html . But it also applies to Python 3.6 https://docs.python.org/3/library/doctest.html and to the current dev https://docs.python.org/dev/library/doctest.html . In the spirit of fixing the new stuff first, I am filing this issue against Python 3.7. Unless someone tells me otherwise, I'll get around to filing similar issues against Python 3.6 and Python 2.7. Then it's my intention to write improvements to the documentation for Python 3.7, 3.6, and 2.7, and submit each of those. It looks like they will be pretty similar, because the library documentation is pretty similar in each version. I'm new to Python issue filing and doc fixing, so I would appreciate correction if (when?) I start to blunder. ---------- assignee: docs at python components: Documentation messages: 286843 nosy: JDLH, docs at python priority: normal severity: normal status: open title: Doctest documentation unclear about multi-line fixtures type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 03:57:22 2017 From: report at bugs.python.org (reason) Date: Fri, 03 Feb 2017 08:57:22 +0000 Subject: [New-bugs-announce] [issue29429] Requests package is incompatible with py2exe Message-ID: <1486112242.43.0.799450044508.issue29429@psf.upfronthosting.co.za> New submission from reason: I use py2exe to compile some py files importing 'Requests' package into executable files user Windows.But I get unexpected exception , 'missing modules'. Even I tried to specify the '-p requests',I still got failure. ---------- messages: 286846 nosy: reason priority: normal severity: normal status: open title: Requests package is incompatible with py2exe type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 04:13:14 2017 From: report at bugs.python.org (Lucas Moeskops) Date: Fri, 03 Feb 2017 09:13:14 +0000 Subject: [New-bugs-announce] [issue29430] zipfile: invalid link Message-ID: <1486113194.67.0.258347417914.issue29430@psf.upfronthosting.co.za> New submission from Lucas Moeskops: The ZipFile documentation shows a link to the PKZip Application Node. This link, with address "https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT" goes to a "Page Not Found" document. ---------- messages: 286847 nosy: lucasmus priority: normal severity: normal status: open title: zipfile: invalid link versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 04:37:45 2017 From: report at bugs.python.org (lamby) Date: Fri, 03 Feb 2017 09:37:45 +0000 Subject: [New-bugs-announce] [issue29431] Add a PYTHONREVERSEDICTKEYORDER environment variable Message-ID: <1486114665.09.0.174630363127.issue29431@psf.upfronthosting.co.za> New submission from lamby: Due to implementation changes, since CPython 3.6 dict keys are returned in insertion order. However, in order to test for reproducible builds [0], it would be convenient to be able to reverse this ordering; we would then run a build of an arbitrary package both with and without this flag and compare the resulting binary. (We already run such a testing framework, so specifying this environment variable would be trivial. Note that this "reverse" would actually find more issues than simply relying on the pre-3.6 non-deterministic behaviour.) This patch changes the behaviour of: * for x in d: * d.popitem() * d.items() * _PyDict_Next [0] https://reproducible-builds.org/ ---------- components: Interpreter Core files: 0001-Add-a-PYTHONREVERSEDICTKEYORDER-environment-variable.patch keywords: patch messages: 286849 nosy: lamby priority: normal severity: normal status: open title: Add a PYTHONREVERSEDICTKEYORDER environment variable type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file46499/0001-Add-a-PYTHONREVERSEDICTKEYORDER-environment-variable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 06:25:24 2017 From: report at bugs.python.org (Martin Teichmann) Date: Fri, 03 Feb 2017 11:25:24 +0000 Subject: [New-bugs-announce] [issue29432] wait_for(gather(...)) logs weird error message Message-ID: <1486121124.44.0.178086142975.issue29432@psf.upfronthosting.co.za> New submission from Martin Teichmann: when waiting for a gather that times out, everything works as expected, yet a weird error message is logged. To give a minimal example: import asyncio @asyncio.coroutine def main(): try: sleep = asyncio.sleep(0.2) yield from asyncio.wait_for(asyncio.gather(sleep), timeout=0.1) except asyncio.TimeoutError: print("timed out: fine") yield from asyncio.sleep(0.1) asyncio.get_event_loop().run_until_complete(main()) This outputs: timed out: fine _GatheringFuture exception was never retrieved future: <_GatheringFuture finished exception=CancelledError()> concurrent.futures._base.CancelledError As you can see, I used the pre-3.5 syntax so I could test whether it works on older systems. No, it doesn't. I wrote a unit test for this problem, unfortunately I couldn't solve it yet. ---------- components: asyncio messages: 286858 nosy: Martin.Teichmann, gvanrossum, yselivanov priority: normal pull_requests: 24 severity: normal status: open title: wait_for(gather(...)) logs weird error message versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 06:43:19 2017 From: report at bugs.python.org (sedrubal) Date: Fri, 03 Feb 2017 11:43:19 +0000 Subject: [New-bugs-announce] [issue29433] any, all and sum should accept variadic args Message-ID: <1486122199.09.0.757475243638.issue29433@psf.upfronthosting.co.za> New submission from sedrubal: any, all and sum (and maybe some other functions) should accept variadic args. It should be possible to do things like this: >>> any(True, False, True) True >>> all(True, False, True) False >>> sum(1, 2, 3) 6 This was compliant to max and min behaviour: >>> max(1, 2, 3) 3 >>> min(1, 2, 3) 1 ---------- messages: 286859 nosy: sedrubal priority: normal severity: normal status: open title: any, all and sum should accept variadic args type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 07:16:12 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 03 Feb 2017 12:16:12 +0000 Subject: [New-bugs-announce] [issue29434] tuple.__repr__ may segv when it contains NULL Message-ID: <1486124172.44.0.836163463521.issue29434@psf.upfronthosting.co.za> New submission from INADA Naoki: sys.getobjects() contains tuples including NULLs. Even without pydebug, tuple under construction can be exposed accidentally. Allowing repr() for such tuples ease investigating what is the tuple. ---------- components: Interpreter Core files: tuple-repr-NULL.patch keywords: patch messages: 286861 nosy: inada.naoki priority: normal severity: normal status: open title: tuple.__repr__ may segv when it contains NULL versions: Python 3.7 Added file: http://bugs.python.org/file46501/tuple-repr-NULL.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 09:37:33 2017 From: report at bugs.python.org (Thom Wiggers) Date: Fri, 03 Feb 2017 14:37:33 +0000 Subject: [New-bugs-announce] [issue29435] Allow to pass fileobj to is_tarfile Message-ID: <1486132653.21.0.166387912558.issue29435@psf.upfronthosting.co.za> New submission from Thom Wiggers: The tarfile.is_tarfile() function only supports opening from paths. However, the `Tarfile` class also supports opening from `fileobj`s. It would be useful if the is_tarfile function would also accept those. For reference, this is the current implementation: https://github.com/python/cpython/blob/fcc3915a266b6cd220483c7020de0d71e293b2cb/Lib/tarfile.py#L2432 ---------- components: Library (Lib) messages: 286869 nosy: twiggers priority: normal severity: normal status: open title: Allow to pass fileobj to is_tarfile type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 11:56:31 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Fri, 03 Feb 2017 16:56:31 +0000 Subject: [New-bugs-announce] [issue29436] Compilation failure against Android NDK r14 beta 2 Message-ID: <1486140991.0.0.176511214208.issue29436@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: Since Android NDK r14 beta 2, unified headers provide langinfo.h but there's no nl_langinfo() in it, causing linking failures: libpython3.7m.a(pylifecycle.o): In function `get_locale_encoding': /home/yen/Projects/python3-android/src/cpython/Python/pylifecycle.c:234: undefined reference to `nl_langinfo' libpython3.7m.a(fileutils.o): In function `_Py_device_encoding': /home/yen/Projects/python3-android/src/cpython/Python/fileutils.c:65: undefined reference to `nl_langinfo' libpython3.7m.a(_localemodule.o): In function `PyLocale_nl_langinfo': /home/yen/Projects/python3-android/src/cpython/./Modules/_localemodule.c:447: undefined reference to `nl_langinfo' Or compiler errors due to implicit function declarations if the patch at issue22747 is applied. nl_langinfo.patch fixes it by adding some extra guarding macros. Added some people from issue22747 to the nosy list, where the last change about langinfo.h and Android occurred. ---------- components: Build files: nl_langinfo.patch keywords: patch messages: 286877 nosy: Chi Hsuan Yen, haypo, skrah, xdegaye priority: normal severity: normal status: open title: Compilation failure against Android NDK r14 beta 2 type: compile error versions: Python 3.7 Added file: http://bugs.python.org/file46503/nl_langinfo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 12:48:05 2017 From: report at bugs.python.org (Mike) Date: Fri, 03 Feb 2017 17:48:05 +0000 Subject: [New-bugs-announce] [issue29437] installation not listed for all users Message-ID: <1486144085.37.0.437097595793.issue29437@psf.upfronthosting.co.za> New submission from Mike: When installing Python 3.6 using the official installer and selecting "install for all users" from an account with admin privileges, the installation completes successfully and it shows in the list of installed programs for that user. However, because it's installation key is written into HKEY_CURRENT_USER, it is listed as installed program only for the user that ran the installation. While Python still seems to run from another account, it is not listed as an installed program for the other user. In the "install for all users" case, it should be registered in HKEY_LOCAL_MACHINE, instead of HKEY_CURRENT_USER. ---------- components: Installation, Windows messages: 286880 nosy: mray, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: installation not listed for all users versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 3 19:52:56 2017 From: report at bugs.python.org (Audric Schiltknecht) Date: Sat, 04 Feb 2017 00:52:56 +0000 Subject: [New-bugs-announce] [issue29438] SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 Message-ID: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za> New submission from Audric Schiltknecht: I've managed to create a minimal test file that causes python to crashe when run with python 3.6.0 (packaged in my distribution or from hg repository), 3.6 branch from hg repository and 3.7 branch from hg repository, but works fine on 3.5.3 and 3.5 branch. It also does not crash when python is compiled with '--with-pydebug' option (3.6/3.7) $ uname -a Linux 4.8.13-1-ARCH #1 SMP PREEMPT Fri Dec 9 07:24:34 CET 2016 x86_64 GNU/Linux $ python --version Python 3.6.0 $ pip freeze appdirs==1.4.0 packaging==16.8 pyparsing==2.1.10 python-dateutil==2.6.0 six==1.10.0 SQLAlchemy==1.1.5 To reproduce, use the attached file (minimal_crash.py): $ virtualenv3 venv $ source venv/bin/activate $ pip install sqlalchemy Run once to create DB and insert some stuff into it (no crash): $ ./minimal_crash.py -d sqlite:///crash.db -v -c Then re-run same thing WITHOUT re-creating the base: $ ./minimal_crash.py -d sqlite:///crash.db -v INFO:__main__:Connecting to DB 'sqlite:///crash.db' Segmentation fault (core dumped) Runing with GDB: https://gist.github.com/audricschiltknecht/5564034c5aac78d881e03f29e069a8f5 ---------- files: minimal_crash.py messages: 286902 nosy: audric priority: normal severity: normal status: open title: SIGSEGV in PyObject_Malloc on python 3.6 and 3.7 type: crash versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46505/minimal_crash.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 00:07:30 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 04 Feb 2017 05:07:30 +0000 Subject: [New-bugs-announce] [issue29439] _decimal on Android requires linking with libm Message-ID: <1486184850.1.0.687785443954.issue29439@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: Just like issue21668, _decimal requires -lm on Android. This wasn't fixed because _decimal didn't build before issue26846 lands. More specificially, log10 is called https://hg.python.org/cpython/file/tip/Modules/_decimal/libmpdec/mpdecimal.c#l7862 Added _decimal and Android experts ---------- components: Cross-Build files: decimal.patch keywords: patch messages: 286906 nosy: Alex.Willmer, Chi Hsuan Yen, skrah, xdegaye priority: normal severity: normal status: open title: _decimal on Android requires linking with libm type: behavior versions: Python 3.7 Added file: http://bugs.python.org/file46506/decimal.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 00:18:54 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 04 Feb 2017 05:18:54 +0000 Subject: [New-bugs-announce] [issue29440] _dbm requires -lgdbm if gdbm is built as static libraries Message-ID: <1486185534.28.0.954859942515.issue29440@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: In setup.py, _dbm links to gdbm_compat only. If gdbm is built as dynamic libraries, libgdbm_compat.so has a NEEDED flag for libgdbm.so, so both symbols in libgdbm and libgdbm_compat can be used. However, as static libraries does not provide such a flag, importing _dbm raises ImportError: shell at ASUS_Z00E_2:/data/local/tmp $ python3.7m -c 'import _dbm' Traceback (most recent call last): File "", line 1, in ImportError: dlopen failed: cannot locate symbol "gdbm_errno" referenced by "/data/local/tmp/python3/usr/lib/python3.7/lib-dynload/_dbm.cpython-37m.so"... gdbm_errno is a symbol in libgdbm.a. gdbm manual [1] suggests linking to both libraries, too. [1] http://www.gnu.org.ua/software/gdbm/manual/html_node/Compatibility.html ---------- components: Build files: gdbm.patch keywords: patch messages: 286907 nosy: Chi Hsuan Yen priority: normal severity: normal status: open title: _dbm requires -lgdbm if gdbm is built as static libraries type: compile error versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46507/gdbm.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 00:49:52 2017 From: report at bugs.python.org (Berker Peksag) Date: Sat, 04 Feb 2017 05:49:52 +0000 Subject: [New-bugs-announce] [issue29441] Update examples to use async and await keywords in asyncio-task.rst Message-ID: <1486187392.27.0.919616068978.issue29441@psf.upfronthosting.co.za> New submission from Berker Peksag: Attached patch converts all examples that use @coroutine decorator in Doc/library/asyncio-task.rst. I also removed the generator example at https://docs.python.org/3/library/asyncio-task.html#example-coroutine-displaying-the-current-date See issue 29407 for context. ---------- assignee: docs at python components: Documentation, asyncio files: update-examples-task.diff keywords: patch messages: 286911 nosy: berker.peksag, docs at python, gvanrossum, yselivanov priority: normal severity: normal stage: patch review status: open title: Update examples to use async and await keywords in asyncio-task.rst type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46508/update-examples-task.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 02:26:28 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Sat, 04 Feb 2017 07:26:28 +0000 Subject: [New-bugs-announce] [issue29442] Use argparse and drop dirty optparse hacks in setup.py Message-ID: <1486193188.24.0.532905655294.issue29442@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: The change is clear and self-explained. See the patch. Motivations: 1. The hack "To prevent optparse from raising an exception..." works for single letter flags (-I, -L, etc.) only. I plan to add --sysroot related codes for Android builds and I don't want more hacks. Apparently argparse does not need this hack as it can parse all known flags before throwing an error 2. optparse is deprecated Add the developer that introduced this hack. Also Serhiy, who sseems interested in removing optparse from the code base. (issue18973, issue18971) ---------- components: Build files: setup-argparse.patch keywords: patch messages: 286922 nosy: Chi Hsuan Yen, brett.cannon, serhiy.storchaka priority: normal severity: normal status: open title: Use argparse and drop dirty optparse hacks in setup.py type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file46511/setup-argparse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 10:29:17 2017 From: report at bugs.python.org (Dave Brondsema) Date: Sat, 04 Feb 2017 15:29:17 +0000 Subject: [New-bugs-announce] [issue29443] Re-running Windows installer should have option to set PATH Message-ID: <1486222157.85.0.184960393536.issue29443@psf.upfronthosting.co.za> New submission from Dave Brondsema: If you miss the checkbox to set the "PATH" when installing Python for the first time, there isn't any easy way to set it again. (And for new programmers, having it set automatically is extremely useful). Uninstalling and re-installing does work to get PATH set, but that isn't ideal. When you re-run the installer it does offer "Modify" and "Repair" options, but neither of those let you set the PATH. It would be nice if "Modify" did offer that option. ---------- components: Installation, Windows messages: 286968 nosy: brondsem, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Re-running Windows installer should have option to set PATH type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 11:23:03 2017 From: report at bugs.python.org (WGH) Date: Sat, 04 Feb 2017 16:23:03 +0000 Subject: [New-bugs-announce] [issue29444] Out-of-bounds buffer access in match_getslice_by_index Message-ID: <1486225383.48.0.902108011161.issue29444@psf.upfronthosting.co.za> New submission from WGH: In [1]: import re In [2]: b = bytearray(b'A'*100) In [3]: m = re.search(b'A*', b) In [4]: m.group() Out[4]: b'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' In [5]: del b[:] In [6]: m.group() Out[6]: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x08\x9a\xc4\xb2i\x7f\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' I will attach the patch shortly. ---------- components: Regular Expressions messages: 286974 nosy: WGH, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Out-of-bounds buffer access in match_getslice_by_index type: security versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 15:29:53 2017 From: report at bugs.python.org (Guillaume Boudreau) Date: Sat, 04 Feb 2017 20:29:53 +0000 Subject: [New-bugs-announce] [issue29445] http.client: missing response headers when malformed header is part of the response Message-ID: <1486240193.44.0.0804410028853.issue29445@psf.upfronthosting.co.za> New submission from Guillaume Boudreau: Tested using urllib3 1.20 ``` >>> import urllib3 >>> http = urllib3.PoolManager() >>> r = http.request('GET', 'https://online.chasecanada.ca/ChaseCanada_Consumer/Login.do') >>> r.status 200 >>> r.headers HTTPHeaderDict({'Date': 'Sat, 04 Feb 2017 20:09:21 GMT'}) >>> ``` I'm pretty sure the problem is caused by an invalid HTTP header returned by the server: HTTP/1.1 200 OK Date: Sat, 04 Feb 2017 19:16:34 GMT My Param: None [...] It directly follows the Date response header, which is returned fine, but since no other response headers is returned, I think this broken header is breaking the HTTP response headers parser. Of note: the `http.client.HTTPresponse.headers` object (`HTTPMessage`) shows all headers in `_payload`, but only the `Date` header in `_headers`. Thus why I think this is a http.client issue, and not a urllib3 issue. ---------- components: Library (Lib) messages: 286987 nosy: gboudreau priority: normal severity: normal status: open title: http.client: missing response headers when malformed header is part of the response type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 4 16:24:25 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Feb 2017 21:24:25 +0000 Subject: [New-bugs-announce] [issue29446] Improve tkinter 'import *' situation Message-ID: <1486243465.34.0.0929989866435.issue29446@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Tkinter naming was designed so that 'from tkinter import *' can work, in the sense of not conflicting with built-in and stdlib module names. But there are currently two problems. 1. The current doc ...to use Tkinter all you need is a simple import statement: import tkinter Or, more often: from tkinter import * over-promotes 'import *' as the common and therefore normal import (as opposed to a convenience for interactive use). It neglects the alternatives 'import tkinter as tk' or 'from tkinter import Tk, ...', and consequently makes no mention of the relative advantages. 2. The current code does not define __all__. So the stdlib imports of enum, re, and sys get carried over with 'import *'. Guido recommends defining __all__ to prevent this.* Since tkinter defines about 160 names, and since there are only 3 names to block, and there are used pretty sparingly, I prefer the uglier alternative of renaming with underscores: 'import enum as _enum', etc. I will work on patches. Since the doc change can apply to all current versions while the code change might be restricted to 3.7, I will keep then separate. * From pydev thread 'Imports with underscores', 2017-1-9: "I would focus on changing habits to discourage "import *" rather than uglifying all new code with this "os as _os" pattern. Very occasionally one designs a module to explicitly support "import *", and that usually entails using __all__ (like it or not), making the problem go away without uglifying the code." ---------- components: Tkinter messages: 286996 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal stage: test needed status: open title: Improve tkinter 'import *' situation type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 00:39:42 2017 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Feb 2017 05:39:42 +0000 Subject: [New-bugs-announce] [issue29447] Add os.PathLike support to the tempfile module Message-ID: <1486273182.96.0.640027026479.issue29447@psf.upfronthosting.co.za> New submission from Brett Cannon: The various classes in the tempfile module could implement os.PathLike. ---------- components: Library (Lib) messages: 287036 nosy: brett.cannon priority: normal severity: normal status: open title: Add os.PathLike support to the tempfile module type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 00:41:24 2017 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Feb 2017 05:41:24 +0000 Subject: [New-bugs-announce] [issue29448] Implement os.Pathlike for importlib.machinery Message-ID: <1486273284.58.0.20381224055.issue29448@psf.upfronthosting.co.za> New submission from Brett Cannon: Various classes in importlib.machinery define a 'path' attribute which could also be exposed through the os.PathLike interface. ---------- components: Library (Lib) messages: 287037 nosy: brett.cannon priority: normal severity: normal status: open title: Implement os.Pathlike for importlib.machinery _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 02:37:48 2017 From: report at bugs.python.org (Jyotirmoy Bhattacharya) Date: Sun, 05 Feb 2017 07:37:48 +0000 Subject: [New-bugs-announce] [issue29449] clear() should return prior state in threading.Event Message-ID: <1486280268.11.0.922529049977.issue29449@psf.upfronthosting.co.za> New submission from Jyotirmoy Bhattacharya: The clear() method for Event objects currently does not return anything. It would be useful to have it return the state of the Event prior to it being cleared. This would be useful since multiple threads may wake up from an event at the same time and all may try to clear() the event. A return value from clear will indicate to a thread if it won the race to clear the event. ---------- components: Library (Lib) messages: 287039 nosy: jmoy priority: normal severity: normal status: open title: clear() should return prior state in threading.Event type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 04:44:20 2017 From: report at bugs.python.org (Omar Sandoval) Date: Sun, 05 Feb 2017 09:44:20 +0000 Subject: [New-bugs-announce] [issue29450] xattr functions aren't in os.supports_fd, os.supports_follow_symlinks Message-ID: <1486287860.62.0.802712636976.issue29450@psf.upfronthosting.co.za> New submission from Omar Sandoval: {get,list,remove,set}xattr all support fds and follow_symlinks, but they are not in the os.supports_fds and os.supports_follow_symlinks sets. The attached patch adds them. There are no HAVE_* features for the f and l variants of these syscalls since it's an all-or-nothing thing, so we always add them if the functions are defined. ---------- components: Extension Modules files: xattrsupports.patch keywords: patch messages: 287042 nosy: Omar Sandoval, benjamin.peterson priority: normal severity: normal status: open title: xattr functions aren't in os.supports_fd, os.supports_follow_symlinks type: enhancement versions: Python 3.7 Added file: http://bugs.python.org/file46522/xattrsupports.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 05:09:13 2017 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Feb 2017 10:09:13 +0000 Subject: [New-bugs-announce] [issue29451] Use _PyArg_Parser for _PyArg_ParseStack(): support positional only arguments Message-ID: <1486289353.72.0.801621994712.issue29451@psf.upfronthosting.co.za> New submission from STINNER Victor: Serhiy Storshaka wrote a kind of cache for PyArg_ParseTupleAndKeywords(): _PyArg_Parser structure used by _PyArg_ParseTupleAndKeywordsFast(). It makes argument parser much faster. Would it be possible to modify it to be able to use it in _PyArg_ParseStack(). (Would it be faster?) See also issue #29419 "Argument Clinic: inline PyArg_UnpackTuple and PyArg_ParseStack(AndKeyword)?" for a different kind of optimization. ---------- components: Interpreter Core messages: 287043 nosy: haypo, inada.naoki, serhiy.storchaka priority: normal severity: normal status: open title: Use _PyArg_Parser for _PyArg_ParseStack(): support positional only arguments type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 05:09:27 2017 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Feb 2017 10:09:27 +0000 Subject: [New-bugs-announce] [issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate Message-ID: <1486289367.55.0.0747777354765.issue29452@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch changes index(), insert() and rotate() functions of the collections.deque type to use FASTCALL calling convention. I chose to only modify these functions since they use METH_VARARGS which requires to create a temporary tuple, whereas other functions use METH_NOARGS or METH_O which is already fast ;-) I know that Raymond, maintainer of the collections module, is not a big fan of Argument Clinic ;-) So I wrote the minimum change and chose to not use Argument Clinic yet. By the way, the index() method has the signature "D.index(value, [start, [stop]])" which is not supported by Argument Clinic yet: see issue #29299. For these reasons, I propose to wait to convert collections.deque to Argument Clinic, it can be done later. Ok, now the cool part: it makes these methods faster ;-) * d.rotate(): 1.10x faster * d.rotate(1): 1.24x faster * d.insert(): 1.18x faster * d.index(): 1.24x faster $ ./python -m perf timeit -s 'import collections; d=collections.deque()' 'd.rotate()' --compare-to=../default-ref/python Median +- std dev: [ref] 70.5 ns +- 0.9 ns -> [patch] 64.2 ns +- 0.3 ns: 1.10x faster (-9%) $ ./python -m perf timeit -s 'import collections; d=collections.deque()' 'd.rotate(1)' --compare-to=../default-ref/python Median +- std dev: [ref] 107 ns +- 1 ns -> [patch] 86.2 ns +- 1.1 ns: 1.24x faster (-20%) $ ./python -m perf timeit -s 'import collections' 'd=collections.deque(); d.insert(0, None); d.insert(1, None); d.insert(2, None); d.insert(3, None); d.insert(4, None)' --compare-to=../default-ref/python -p3 Median +- std dev: [ref] 699 ns +- 6 ns -> [patch] 591 ns +- 5 ns: 1.18x faster (-15%) $ ./python -m perf timeit -s 'import collections; d=collections.deque((None,))' 'd.index(None)' --compare-to=../default-ref/python Median +- std dev: [ref] 115 ns +- 1 ns -> [patch] 92.5 ns +- 0.8 ns: 1.24x faster (-19%) ---------- files: deque.patch keywords: patch messages: 287044 nosy: haypo, rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: Use FASTCALL for collections.deque methods: index, insert, rotate type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46523/deque.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 10:17:27 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Sun, 05 Feb 2017 15:17:27 +0000 Subject: [New-bugs-announce] [issue29453] Remove reference to undefined dictionary ordering in Tutorial Message-ID: <1486307847.14.0.0393957719878.issue29453@psf.upfronthosting.co.za> New submission from Jim Fasarakis-Hilliard: Removes `keys = sorted(keywords.keys())` from function example and removes the text that describes why this was necessary. As per PEP 468, this note is obsolete for 3.6+ Also changes the ordering of the function call to match the previous output. ---------- assignee: docs at python components: Documentation files: controlflowdiff.patch keywords: patch messages: 287048 nosy: Jim Fasarakis-Hilliard, docs at python priority: normal severity: normal status: open title: Remove reference to undefined dictionary ordering in Tutorial versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46524/controlflowdiff.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 11:18:38 2017 From: report at bugs.python.org (Tom) Date: Sun, 05 Feb 2017 16:18:38 +0000 Subject: [New-bugs-announce] [issue29454] Shutting down consumer on a remote queue Message-ID: <1486311518.72.0.101525789296.issue29454@psf.upfronthosting.co.za> New submission from Tom: Using code adapted from the example in the docs (https://docs.python.org/3/library/multiprocessing.html#using-a-remote-manager), if you create a remote queue server, a producer which puts items in the queue and a consumer which consumes elements from the queue. If the consumer gets killed and restarted again, it misses one item from the queue. For a reproducable example see the stackoverflow reference below. Expected: items stay in the queue until a consumer consumes it Happens: one item still gets consumed from the queue even if after a consumer gets killed Version: Python 3.6.0 OS: Ubuntu 16.10 reference: http://stackoverflow.com/questions/42052248/remote-queue-consumer-misses-first-message-after-restart ---------- messages: 287055 nosy: Semi priority: normal severity: normal status: open title: Shutting down consumer on a remote queue versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 22:39:07 2017 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Feb 2017 03:39:07 +0000 Subject: [New-bugs-announce] [issue29455] Mention coverage.py in trace module documentation Message-ID: <1486352347.76.0.0578982981399.issue29455@psf.upfronthosting.co.za> New submission from Brett Cannon: In the trace module it would be nice to also mention that coverage.py is available. ---------- assignee: docs at python components: Documentation messages: 287075 nosy: brett.cannon, docs at python priority: normal severity: normal status: open title: Mention coverage.py in trace module documentation type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 5 23:27:52 2017 From: report at bugs.python.org (Wonsup Yoon) Date: Mon, 06 Feb 2017 04:27:52 +0000 Subject: [New-bugs-announce] [issue29456] bug in unicodedata.normalize: u1176 Message-ID: <1486355272.29.0.0894514518656.issue29456@psf.upfronthosting.co.za> New submission from Wonsup Yoon: unicodedata can't normalize(NFC) hangul strings which contain \u1176(HANGUL JUNGSEONG A-O). >>> from unicodedata import normalize >>> normalize("NFC", "\u1100\u1176\u11a8") '?' => should be "\u1100\u1176\u11a8" not '?' (\uae4d) I attached a patch for this issue. (Fixing boundary of modern medial vowels) ---------- components: Unicode files: u1176.patch keywords: patch messages: 287077 nosy: ezio.melotti, haypo, pusnow priority: normal severity: normal status: open title: bug in unicodedata.normalize: u1176 versions: Python 2.7, Python 3.6 Added file: http://bugs.python.org/file46535/u1176.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 01:41:40 2017 From: report at bugs.python.org (Hugo Osvaldo Barrera) Date: Mon, 06 Feb 2017 06:41:40 +0000 Subject: [New-bugs-announce] [issue29457] strftime('%x') does not use my locale Message-ID: <1486363300.36.0.613754876721.issue29457@psf.upfronthosting.co.za> New submission from Hugo Osvaldo Barrera: As the the posix spec for strftime: %c The preferred date and time representation for the current locale. %x The preferred date representation for the current locale without the time. However, python doesn't seem to respect this: $ python3.5 -c "from datetime import datetime; print(datetime.now().strftime('%x'))" 02/06/17 $ date +%x # This one is right: 2017-02-06 $ echo $LC_TIME en_DK.UTF-8 * The same applies for '%c'. * The same applies for other python versions. * The same applies regardless of LC_TIME and LANG. * The same applies to time.strftime() * I tried a few different LC_TIME values, with the same result every time. ---------- components: Extension Modules messages: 287082 nosy: hobarrera priority: normal severity: normal status: open title: strftime('%x') does not use my locale type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 02:27:36 2017 From: report at bugs.python.org (Maciej Obarski) Date: Mon, 06 Feb 2017 07:27:36 +0000 Subject: [New-bugs-announce] [issue29458] random.seed version=1 behavior Message-ID: <1486366056.6.0.968381064219.issue29458@psf.upfronthosting.co.za> New submission from Maciej Obarski: random.seed version=1 wont generate the same randint sequences in python2 and python3 Python 2.7: >>> seed(1); randint(0,100) 13 Python 3.6: >>> seed(1,version=1); randint(0,100) 17 The documentation states that versio=1 is "provided for reproducing random sequences from older versions of Python" and "If a new seeding method is added, then a backward compatible seeder will be offered." ---------- components: Extension Modules messages: 287089 nosy: Maciej Obarski priority: normal severity: normal status: open title: random.seed version=1 behavior type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:00:11 2017 From: report at bugs.python.org (irdb) Date: Mon, 06 Feb 2017 08:00:11 +0000 Subject: [New-bugs-announce] [issue29459] `__contains__` and `get` methods for match objects? Message-ID: <1486368011.75.0.401714465963.issue29459@psf.upfronthosting.co.za> New submission from irdb: __getitem__ was added to match objects as a resolution of issue24454. Wouldn't it be nice to also have `__contains__` and `get` methods for match objects? Is it even feasible to implement them in neat way? They should work similar to dictionaries, i.e: ``` match = re.match('(?Pa)', 'a') match.get('b') # should return None match.get(1) # should return 'a' 'a' in match # True 'b' in match # False ``` ---------- components: Library (Lib) messages: 287096 nosy: eric.smith, irdb, mrabarnett, serhiy.storchaka priority: normal severity: normal status: open title: `__contains__` and `get` methods for match objects? type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 03:09:51 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 08:09:51 +0000 Subject: [New-bugs-announce] [issue29460] Speed up _PyArg_NoKeywords() and like Message-ID: <1486368591.1.0.81893713474.issue29460@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and _PyArg_NoPositional() macros. This eliminates the overhead of the cross-module function call in common case. This idea was previously discussed in issue26822 and raised again in issue29452. ---------- components: Interpreter Core files: _PyArg_NoKeywords_macro.patch keywords: patch messages: 287098 nosy: haypo, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Speed up _PyArg_NoKeywords() and like type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46537/_PyArg_NoKeywords_macro.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 04:41:28 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 09:41:28 +0000 Subject: [New-bugs-announce] [issue29461] Experiment usage of likely/unlikely in CPython core Message-ID: <1486374088.9.0.781114039214.issue29461@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch is an attempt to use the GCC/Clang __builtin_expect() attribute to provide the compiler with branch prediction information, it adds _Py_likely() and _Py_unlikely() macros, similar to the Linux kernel macros. I always wanted to experiment this change. I opened this issue to collect information and benchmark results to take a decision. I doubt that the change will really make Python faster, there is a risk of modifying a lot of code for no value, or worse: make Python slower. Extract of GCC doc: "as programmers are notoriously bad at predicting how their programs actually perform." My patch marks error cases as unlikely. A profiler like Linux perf should be used to check which branches are less likely, but I tried to use my guesses to expeeriment a first change. Since there is a risk that using such macro makes the code slower, or has no effect, I tried to restrict changes to the hot code and the most common functions/macros: * Py_EnterRecursiveCall() * _PyArg_NoKeywords() * Py_DECREF()... not sure about this case, is it really more likely that refcnt != 0 than refcnt==0? * Functions to call functions: _PyObject_FastCallKeywords(), fast_function(), etc. * etc. I'm not sure about the methodology to benchmark such patch neither. Is it worth it to benchmark a Python compiled without PGO? By the way, does GCC/Clang use __builtin_expect() information when Python is compiled with PGO? If PGO ignores this information, it would be better to not use it, since I now strongly recommend to use PGO. Otherwise, Python performance is too random because of the joy of code placement. Some links on __builtin_expect(): * http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html * http://stackoverflow.com/questions/109710/likely-unlikely-macros-in-the-linux-kernel-how-do-they-work-whats-their * https://news.ycombinator.com/item?id=9411227 ---------- files: likely.patch keywords: patch messages: 287112 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: Experiment usage of likely/unlikely in CPython core type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46539/likely.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 06:28:50 2017 From: report at bugs.python.org (Alessandro Vesely) Date: Mon, 06 Feb 2017 11:28:50 +0000 Subject: [New-bugs-announce] [issue29462] RFC822-comments in email header fields can fool, e.g., get_filename() Message-ID: <1486380530.49.0.923389621241.issue29462@psf.upfronthosting.co.za> New submission from Alessandro Vesely: Comments are allowed almost everywhere in an email message, and should be eliminated before attributing any meaning to a field. In the words of RFC5322, any CRLF that appears in FWS is semantically "invisible". In particular, some note that comments can be used to deceive an email filter. For example, like so: Content-Disposition: attachment; filename=''attached%2E"; filename*1*="%62"; filename*2=(fool filters)at (I don't know which, if any, email clients would execute that batch...) Anyway, removing comments is needed for any structured header field. One is usually interested in the unfolded, de-commented value. It is difficult to do correctly, because of nesting and quoting possibilities. This issue seems to be ignored, except for address lists (there is a getcomment() member in AddrlistClass). Why? ---------- components: email messages: 287119 nosy: ale2017, barry, r.david.murray priority: normal severity: normal status: open title: RFC822-comments in email header fields can fool, e.g., get_filename() type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 09:21:16 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 06 Feb 2017 14:21:16 +0000 Subject: [New-bugs-announce] [issue29463] Change docstring to attribute from first statement. Message-ID: <1486390876.35.0.496966996959.issue29463@psf.upfronthosting.co.za> New submission from INADA Naoki: spin off of #11549. http://bugs.python.org/issue11549#msg130955 > b) Docstring is now an attribute of Module, FunctionDef and ClassDef, > rather than a first statement. Docstring is a special syntactic > construction, it's not an executable code, so it makes sense to separate it. Otherwise, optimizer would have to take extra care not to introduce, change or remove docstring. For example: > > def foo(): > "doc" + "string" > >Without optimizations foo doesn't have a docstring. After folding, however, the first statement in foo is a string literal. This means that docstring depends on the level of optimizations. Making it an attribute avoids the problem. ---------- files: ast-docstring.patch keywords: patch messages: 287136 nosy: haypo, inada.naoki priority: normal severity: normal status: open title: Change docstring to attribute from first statement. versions: Python 3.7 Added file: http://bugs.python.org/file46543/ast-docstring.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 10:22:45 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Feb 2017 15:22:45 +0000 Subject: [New-bugs-announce] [issue29464] Specialize FASTCALL for functions with positional-only parameters Message-ID: <1486394565.83.0.903919283463.issue29464@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch renames METH_FASTCALL to METH_FASTCALL|METH_KEYWORDS and makes bare METH_FASTCALL be used for functions with positional-only parameters. This eliminates small cost that these functions pay for handling empty keywords: calling _PyStack_UnpackDict() and _PyArg_NoStackKeywords(), passing kwnames. This also can slightly reduce stack consumption. ---------- components: Interpreter Core files: fastcall-no-keywords.patch keywords: patch messages: 287143 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Specialize FASTCALL for functions with positional-only parameters type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46544/fastcall-no-keywords.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 12:08:27 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Feb 2017 17:08:27 +0000 Subject: [New-bugs-announce] [issue29465] Add _PyObject_FastCall() to reduce stack consumption Message-ID: <1486400907.96.0.983593243638.issue29465@psf.upfronthosting.co.za> New submission from STINNER Victor: While testing issue #29464 patch, I failed to see a major enhancement on the stack usage of fast calls without keyword arguments. The problem is that functions like _PyObject_FastCallKeywords() and _PyObject_FastCallDict() still have to pass a NULL argument for kwargs/kwnames, and have code to handle keyword arguments. Attached patch adds _PyObject_FastCall() to reduce the stack consumption. At the C level, keyword arguments are almost never used. For example, PyObject_CallFunctionObjArgs() is commonly used, whereas it only uses positional arguments. The patch changes also _PyObject_FastCallKeywords() and _PyObject_FastCallDict() to move the "slow" path creating temporary tuple and dict in a subfunction which is not inlined. The slow path requires more stack memory. Morecall, _PyObject_FastCallKeywords() and _PyObject_FastCallDict() are modified to call _PyObject_FastCall() if there is no keyword. The patch might make function calls without keyword arguments faster, I didn't check. Stack usage. $ ./python -c 'import _testcapi, sys; sys.setrecursionlimit(10**5); n=1000; s=_testcapi.meth_fastcall_stacksize(n); print("%.1f B/call" % (s/n))' * Reference: 832.8 B/call * Patch: 656.6 B/call (-176.2 B) I don't know why the stack usage is not an integer number of bytes? Combined with the issue #29464 "Specialize FASTCALL for functions with positional-only parameters", the stack usage can be even more reduced by a few bytes. See the issue #28870 for the previous work on reducing stack consumption. ---------- components: Interpreter Core files: pyobject_fastcall.patch keywords: patch messages: 287153 nosy: haypo, inada.naoki, serhiy.storchaka priority: normal severity: normal status: open title: Add _PyObject_FastCall() to reduce stack consumption type: resource usage versions: Python 3.7 Added file: http://bugs.python.org/file46545/pyobject_fastcall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 13:36:36 2017 From: report at bugs.python.org (Mark Diekhans) Date: Mon, 06 Feb 2017 18:36:36 +0000 Subject: [New-bugs-announce] [issue29466] pickle does not serialize Exception __cause__ field Message-ID: <1486406196.69.0.481594976881.issue29466@psf.upfronthosting.co.za> New submission from Mark Diekhans: python3 pickle does not serialize the __cause__ field, as shown by the attached demo program. ---------- components: Library (Lib) files: cause_pickle.py messages: 287163 nosy: diekhans priority: normal severity: normal status: open title: pickle does not serialize Exception __cause__ field type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46550/cause_pickle.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 16:11:31 2017 From: report at bugs.python.org (Ted Shaneyfelt) Date: Mon, 06 Feb 2017 21:11:31 +0000 Subject: [New-bugs-announce] [issue29467] Allow return mismatch to be caught by function Message-ID: <1486415491.45.0.543077011727.issue29467@psf.upfronthosting.co.za> New submission from Ted Shaneyfelt: def f(): try: return 0 except: return 1,2 x = f() # x is 0 x,y = f() # proposal: x,y should be 1,2 instead of uncaught TypeError It would make sense to be able to catch [TypeError: 'int' object is not iterable] and return the correct number of values. Yes, the way it's done now, the function is no longer running when it is caught - but is it possible and practical to determine if parameters match before the function returns instead of afterward, allowing the called function to catch the error attempting to return? ---------- components: Interpreter Core messages: 287173 nosy: Ted Shaneyfelt priority: normal severity: normal status: open title: Allow return mismatch to be caught by function type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 22:14:05 2017 From: report at bugs.python.org (Joe Jevnik) Date: Tue, 07 Feb 2017 03:14:05 +0000 Subject: [New-bugs-announce] [issue29468] zipfile should catch ValueError as well as OSError to detect bad seek calls Message-ID: <1486437245.45.0.651838453816.issue29468@psf.upfronthosting.co.za> New submission from Joe Jevnik: In zipfile.py only OSError is checked to see if seek fails: ``` def _EndRecData64(fpin, offset, endrec): """ Read the ZIP64 end-of-archive records and use that to update endrec """ try: fpin.seek(offset - sizeEndCentDir64Locator, 2) except OSError: # If the seek fails, the file is not large enough to contain a ZIP64 # end-of-archive record, so just return the end record we were given. return endrec ``` I belive that this should also catch ValueError so that other file-like objects may be passed to ZipFile. The particular case I ran into was passing an mmap object: ``` """ $ python p.py sys.version_info(major=3, minor=6, micro=0, releaselevel='final', serial=0) [] Traceback (most recent call last): File "p.py", line 34, in with mmap_shared_raw_zipfile(f.name) as zf: File "/usr/lib64/python3.6/contextlib.py", line 82, in __enter__ return next(self.gen) File "p.py", line 23, in mmap_shared_raw_zipfile ZipFile(mm) as zf: File "/usr/lib64/python3.6/zipfile.py", line 1100, in __init__ self._RealGetContents() File "/usr/lib64/python3.6/zipfile.py", line 1163, in _RealGetContents endrec = _EndRecData(fp) File "/usr/lib64/python3.6/zipfile.py", line 264, in _EndRecData return _EndRecData64(fpin, -sizeEndCentDir, endrec) File "/usr/lib64/python3.6/zipfile.py", line 196, in _EndRecData64 fpin.seek(offset - sizeEndCentDir64Locator, 2) ValueError: seek out of range """ from contextlib import contextmanager import mmap import sys from tempfile import NamedTemporaryFile from zipfile import ZipFile print(sys.version_info) @contextmanager def mmap_shared_raw_zipfile(path): """Open a zipfile with mmap shared so the data can be shared in multiple processes. Parameters ---------- path : str The path the zipfile to open. Notes ----- The context manager returns a :class:`zipfile.ZipFile` on enter. """ with open(path) as f, \ mmap.mmap(f.fileno(), 0, mmap.MAP_SHARED, mmap.PROT_READ) as mm, \ ZipFile(mm) as zf: yield zf with NamedTemporaryFile() as f: ZipFile(f, mode='w').close() print(ZipFile(f.name).infolist()) with NamedTemporaryFile() as f: ZipFile(f, mode='w').close() with mmap_shared_raw_zipfile(f.name) as zf: print(zf.infolist()) ``` ---------- components: Library (Lib) messages: 287185 nosy: llllllllll priority: normal severity: normal status: open title: zipfile should catch ValueError as well as OSError to detect bad seek calls versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 6 23:02:38 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 07 Feb 2017 04:02:38 +0000 Subject: [New-bugs-announce] [issue29469] AST-level Constant folding Message-ID: <1486440158.46.0.424511474325.issue29469@psf.upfronthosting.co.za> New submission from INADA Naoki: spin off of #11549. This patch uses code generator to traverse AST. ---------- files: ast-constant-folding.patch keywords: patch messages: 287186 nosy: inada.naoki priority: normal severity: normal status: open title: AST-level Constant folding versions: Python 3.7 Added file: http://bugs.python.org/file46555/ast-constant-folding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 01:22:31 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Tue, 07 Feb 2017 06:22:31 +0000 Subject: [New-bugs-announce] [issue29470] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 Message-ID: <1486448551.68.0.60824192451.issue29470@psf.upfronthosting.co.za> New submission from David Ford (FirefighterBlu3): (Only 3.[56] tested) my application listens on an SSL wrapped port, accepts socket and gets an incoming set of messages. connection time frame is several seconds but due to bad Comcast service frequently we have outages which hang connections. almost every day python crashes as follows: Feb 07 02:36:11 ranger.blue-labs.org python[11816]: *** Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 *** Feb 07 02:36:11 ranger.blue-labs.org python[11816]: *** Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 *** Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 WARNING SSL client handshake has failed: EOF occurred in viola Feb 07 02:36:11 ranger.blue-labs.org python[11816]: ======= Backtrace: ========= Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(+0x70c4b)[0x7f62a84cac4b] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(+0x76fe6)[0x7f62a84d0fe6] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(+0x777de)[0x7f62a84d17de] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(CRYPTO_free+0x1d)[0x7f62a5ceaa6d] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(BN_clear_free+0x58)[0x7f62a5d4bbc8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(RSA_free+0x6f)[0x7f62a5d99a2f] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(EVP_PKEY_free+0x4a)[0x7f62a5dcdcea] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(+0x163780)[0x7f62a5de5780] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(ASN1_template_free+0x450)[0x7f62a5debf00] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(ASN1_template_free+0x567)[0x7f62a5dec017] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(ASN1_item_free+0x1fb)[0x7f62a5dec2fb] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(SSL_CTX_use_certificate+0xc4)[0x7f62a4ee3d14] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(SSL_CTX_use_certificate_chain_file+0x7f)[0x7f62a4ee490f] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0xe77d)[0x7f6 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyCFunction_Call+0xe9)[0x7f62a8ac4be9] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x78a1)[0x7f62a8b3b941] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x92fd8)[0x7f62a8aa7fd8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_CallFunctionObjArgs+0xc2)[0x7f62a8a7dec2] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0x9c46)[0x7f6 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(ssl_parse_clienthello_tlsext+0x648)[0x7f62a4ec9838] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(ssl3_get_client_hello+0x6fa)[0x7f62a4eadeca] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(ssl3_accept+0x66f)[0x7f62a4eb27af] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0xc3a9)[0x7f6 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x843c)[0x7f62a8b3c4dc] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: ======= Backtrace: ========= Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(+0x70c4b)[0x7f62a84cac4b] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(+0x76fe6)[0x7f62a84d0fe6] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(+0x777de)[0x7f62a84d17de] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(CRYPTO_free+0x1d)[0x7f62a5ceaa6d] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(BN_clear_free+0x58)[0x7f62a5d4bbc8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(RSA_free+0x6f)[0x7f62a5d99a2f] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(EVP_PKEY_free+0x4a)[0x7f62a5dcdcea] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(+0x163780)[0x7f62a5de5780] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(ASN1_template_free+0x450)[0x7f62a5debf00] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(ASN1_template_free+0x567)[0x7f62a5dec017] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x5d8e)[0x7f62a8b39e2e] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libcrypto.so.1.0.0(ASN1_item_free+0x1fb)[0x7f62a5dec2fb] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(SSL_CTX_use_certificate+0xc4)[0x7f62a4ee3d14] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(SSL_CTX_use_certificate_chain_file+0x7f)[0x7f62a4ee490f] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0xe77d)[0x7f6 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyCFunction_Call+0xe9)[0x7f62a8ac4be9] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x78a1)[0x7f62a8b3b941] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x92fd8)[0x7f62a8aa7fd8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_CallFunctionObjArgs+0xc2)[0x7f62a8a7dec2] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0x9c46)[0x7f6 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(ssl_parse_clienthello_tlsext+0x648)[0x7f62a4ec9838] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(ssl3_get_client_hello+0x6fa)[0x7f62a4eadeca] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libssl.so.1.0.0(ssl3_accept+0x66f)[0x7f62a4eb27af] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/python3.5/lib-dynload/_ssl.cpython-35m-x86_64-linux-gnu.so(+0xc3a9)[0x7f6 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x843c)[0x7f62a8b3c4dc] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x5d8e)[0x7f62a8b39e2e] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x92fd8)[0x7f62a8aa7fd8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x7ed14)[0x7f62a8a93d14] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0xc5110)[0x7f62a8ada110] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0xc3475)[0x7f62a8ad8475] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x3d6b)[0x7f62a8b37e0b] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x930c5)[0x7f62a8aa80c5] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0xee6)[0x7f62a8b34f86] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x92fd8)[0x7f62a8aa7fd8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x7ed14)[0x7f62a8a93d14] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7f62a8b33da7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1629a2)[0x7f62a8b779a2] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpthread.so.0(+0x7454)[0x7f62a87ff454] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(clone+0x5f)[0x7f62a85427df] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x92fd8)[0x7f62a8aa7fd8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x7ed14)[0x7f62a8a93d14] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0xc5110)[0x7f62a8ada110] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0xc3475)[0x7f62a8ad8475] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x3d6b)[0x7f62a8b37e0b] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x930c5)[0x7f62a8aa80c5] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0xee6)[0x7f62a8b34f86] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalFrameEx+0x88ca)[0x7f62a8b3c96a] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1285e3)[0x7f62a8b3d5e3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_EvalCodeEx+0x23)[0x7f62a8b3d6c3] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x92fd8)[0x7f62a8aa7fd8] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x7ed14)[0x7f62a8a93d14] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyObject_Call+0x47)[0x7f62a8a7d2b7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7f62a8b33da7] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpython3.5m.so.1.0(+0x1629a2)[0x7f62a8b779a2] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libpthread.so.0(+0x7454)[0x7f62a87ff454] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: /usr/lib/libc.so.6(clone+0x5f)[0x7f62a85427df] Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO goodbye3 107.170.82.162 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO disconnect: Thread-797 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 WARNING SSL client handshake has failed: EOF occurred in violation of protocol (_ssl.c:645) Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO goodbye3 107.170.82.162 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO disconnect: Thread-798 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 WARNING SSL client handshake has failed: EOF occurred in violation of protocol (_ssl.c:645) Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO goodbye3 107.170.82.162 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO disconnect: Thread-794 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 WARNING SSL client handshake has failed: EOF occurred in violation of protocol (_ssl.c:645) Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO goodbye3 107.170.82.162 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO disconnect: Thread-796 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 WARNING SSL client handshake has failed: EOF occurred in violation of protocol (_ssl.c:645) Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO goodbye3 107.170.82.162 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: 2017-02-07 02:36:11 INFO disconnect: Thread-795 Feb 07 02:36:11 ranger.blue-labs.org python[11816]: cutils.cpython-35m-x86_64-linux-gnu.so (deleted) i've restarted this under valgrind to debug it. valgrind's startup of python 3.6 is depressingly filled with invalid read of size n, conditional jump/move on uninitialized value, use of uninitialized value; mostly in libpython3.6m. ---------- assignee: christian.heimes components: SSL messages: 287198 nosy: David Ford (FirefighterBlu3), christian.heimes priority: normal severity: normal status: open title: Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0 type: crash versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 04:08:59 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Feb 2017 09:08:59 +0000 Subject: [New-bugs-announce] [issue29471] AST: add an attribute to FunctionDef to distinguish functions from generators and coroutines Message-ID: <1486458539.58.0.744778606798.issue29471@psf.upfronthosting.co.za> New submission from STINNER Victor: Currently, symtable_visit_expr() has browse into the AST tree to look up yield, yield from or await to check if a function is a generator or a coroutine. If we choose to start to work on AST optimizers, I would suggest to add an attribute to ast.FunctionDef to announce if a function is a generator or a coroutine. Currently, the peephole optimizer is unable to remove the deadcode, because otherwise the function is no more detected as a generator: def generator(): if 0: yield # "hack" to get a generator pass By the way, it would be nice to add a keyword similar to "async def" to be able to explicitly "document" generators as generators, and avoid the "if 0: yield" hack, but that's a different topic ;-) I feel less confortable to modify the Python language. ---------- components: Interpreter Core messages: 287216 nosy: haypo, inada.naoki, yselivanov priority: normal severity: normal status: open title: AST: add an attribute to FunctionDef to distinguish functions from generators and coroutines type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 06:57:14 2017 From: report at bugs.python.org (Maurice van der Pot) Date: Tue, 07 Feb 2017 11:57:14 +0000 Subject: [New-bugs-announce] [issue29472] subprocess.communicate with timeout 0 and already terminated process generates TimeoutExpired on Linux Message-ID: <1486468634.65.0.790221754194.issue29472@psf.upfronthosting.co.za> New submission from Maurice van der Pot: This only happens when: - timeout is small enough - at least one stream is redirected to a PIPE When I know for certain that a subprocess has already terminated and I call communicate to retrieve its results with a timeout of 0 (or other small enough value), communicate will always return TimeoutExpired. The cause is that the check on timeout is done before the ready file descriptors are checked: https://hg.python.org/cpython/file/tip/Lib/subprocess.py#l1484. With a small enough timeout, communicate will never check the file descriptors for EOF. >From a user perspective I would expect to be able to use communicate(timeout=0) to get the output for a process that I know has already terminated or to poll without blocking. Is this the intended behaviour of communicate or is it a bug? To me this behaviour is surprising. ---------- components: Library (Lib) messages: 287230 nosy: Griffon26 priority: normal severity: normal status: open title: subprocess.communicate with timeout 0 and already terminated process generates TimeoutExpired on Linux type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 10:21:16 2017 From: report at bugs.python.org (=?utf-8?b?0JLQsNC00LjQvCDQmtCw0YDQsA==?=) Date: Tue, 07 Feb 2017 15:21:16 +0000 Subject: [New-bugs-announce] [issue29473] subprocces check_output Message-ID: <1486480876.24.0.160507485938.issue29473@psf.upfronthosting.co.za> New submission from ????? ????: check_output(['command']) Can't be decoded as it was in 3.5 check_output(['command']).decode('utf-8') returns UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8d in position 2: invalid start byte error. ---------- components: Windows messages: 287239 nosy: paul.moore, steve.dower, tim.golden, zach.ware, ????? ???? priority: normal severity: normal status: open title: subprocces check_output versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 10:59:18 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 07 Feb 2017 15:59:18 +0000 Subject: [New-bugs-announce] [issue29474] Grammatical errors in weakref.WeakValueDictionary docs Message-ID: <1486483158.7.0.401706945265.issue29474@psf.upfronthosting.co.za> New submission from Mariatta Wijaya: https://docs.python.org/3/library/weakref.html?highlight=weakref#weakref.WeakValueDictionary There are grammatical errors in the sentence: These method have the same issues as the and keyrefs() method of WeakKeyDictionary objects. Reported by Arthur Goldberg in https://mail.python.org/pipermail/docs/2017-February/029957.html ---------- assignee: docs at python components: Documentation keywords: easy messages: 287241 nosy: Mariatta, docs at python priority: normal severity: normal status: open title: Grammatical errors in weakref.WeakValueDictionary docs versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 16:26:15 2017 From: report at bugs.python.org (Ben Longbons) Date: Tue, 07 Feb 2017 21:26:15 +0000 Subject: [New-bugs-announce] [issue29475] option to not follow symlinks when globbing Message-ID: <1486502775.77.0.404935971295.issue29475@psf.upfronthosting.co.za> New submission from Ben Longbons: Background: I have a data hierarchy with a lot of "sibling" symlinked directories/files. I want to glob only the non-symlink files, because it's a *huge* performance increase. Before `os.scandir`, I was using a local copy of `glob.py` and calling `os.path.islink` every time, which was faster for *my* use case, but unacceptable for upstreaming. With `os.scandir`, my new patch should be acceptable. The patch includes tests. Current discussion points: * Am I making the right decision to still accept symlinks for fully-literal components (in glob0)? It doesn't apply to my use-case, and I imagine some people might want to handle that case separately. * Are my tests sufficient? I just copied and modified the existing symlink tests. * Should my `flags` TODO be implemented *before* this patch? IMO it would be clearer after, even if it makes the diffs longer. Future discussion points (don't derail): * Should my `flags` TODO be implemented internally (this would significantly shrink any future patches)? (I can work on this) * Should `flags` also be exposed externally? * What additional `flags` might be useful? (my list: GLOB_ERR, GLOB_MARK, ~GLOB_NOSORT, ~GLOB_NOESCAPE, GLOB_PERIOD, GLOB_BRACE, GLOB_TILDE_CHECK, GLOB_ONLYDIR (+ equivalent for files - also, why doesn't `os.scandir` have accessors for the other types without doing an unnecessary stat?)) * Is there a bitwise enum (or equivalently, enum set) in the standard library so `flags` can get sane reprs? (I've implemented this before, but imagine it would be overwhelmed with bikeshedding if it doesn't exist yet) * Should `pathlib` really be implementing globbing on its own? That makes it hard to ensure feature parity. Perhaps the `glob` module needs some additional APIs? (I don't want to work on `pathlib` itself) ---------- components: Library (Lib) files: python-glob-symlink.diff keywords: patch messages: 287256 nosy: o11c priority: normal severity: normal status: open title: option to not follow symlinks when globbing type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file46566/python-glob-symlink.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 7 22:24:34 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Feb 2017 03:24:34 +0000 Subject: [New-bugs-announce] [issue29476] Simplify set_add_entry() Message-ID: <1486524274.18.0.162976124513.issue29476@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Dummy entries created by deletions are currently handled in two places. The code in set_add_entry() tracks a freeslot to allow dummy slots to be reused when new elements are inserted. The dummies are also eliminated during resizing. The freeslot checks are made in the inner-loop of set_add_entry() and will only eliminate a few of the dummies (ones that happen to be in a slot that we want to use again). In contrast, the resize routine eliminates 100% of the dummy entries -- this is where most dummies get reclaimed. This is a preliminary draft of an idea to only use resizing for dummy reclamation. It proposes eliminating the freeslot reuse step in set_add_entry(). One advantage is that the patch nicely simplifies the code in set_add_entry and makes its inner-loop tighter (eliminating one memory access out of the two on each iteration). With the advent of linear probing and the 60% set load factor, set resizing has become very cheap. One issue with the current design is the while a few dummies get reclaimed earlier, others are left alive longer, causing more collisions during lookups. The reuse of a few dummies defers the resizing step that would actually clear out all of the dummies. Another thought is that the proposal gives a better separation of concerns. Insertion focuses on adding entries without making inner loop checks for an uncommon case (the relevant note in dictobject.c says this is uncommon by a factor of hundreds). The patch leaves the dummy cleanup to the fast, efficient resizing step. Some areas for exploration: * We know that the benefit to set_add_entry() will reduce the cost of building a set (which is the common case). It simply does less work by using less code overall and by having less code in the inner loop (see the disassembly below (1) to see that we're now down to one memory access per iteration). That said, it would be nice to quantify whether this is a small improvement or a big one (I expect the answer will be different for CLang vs GCC vs MSC, for 32-bit builds versus 64-builds, and for ARM versus x86, etc). * It would also be nice see if there is an observable small benefit or small detriment to the uncommon case of building a set followed by cycling back and forth between removing elements and adding new elements. In any case, the simplification of the code in set_add_entry() will be nice and it would be good to have a separation of concerns with only set_resize being responsible for clearing out dummies in a single high-speed pass. (1) Inner-loop for the new set_add_entry() featuring only one memory access per iteration: L383: cmpq %r9, %rbx ; entry < start + LINEAR_PROBES je L406 L388: addq $16, %rbx ; entry++ movq 8(%rbx), %rax ; load entry->hash from memory testq %rax, %rax ; entry->hash == 0 jne L382 ; until zero found skip next test cmpq $0, (%rbx) ; entry->key == NULL je L374 ; return entry L382: cmpq %rax, %r15 ; entry->hash == hash jne L383 ; loop back <... process to equality test > ---------- assignee: rhettinger components: Interpreter Core files: set_no_dummy_reuse.diff keywords: patch messages: 287272 nosy: rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: Simplify set_add_entry() versions: Python 3.7 Added file: http://bugs.python.org/file46568/set_no_dummy_reuse.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 04:30:21 2017 From: report at bugs.python.org (Malthe Borch) Date: Wed, 08 Feb 2017 09:30:21 +0000 Subject: [New-bugs-announce] [issue29477] Lambda with complex arguments is ctx STORE Message-ID: <1486546221.26.0.696081579931.issue29477@psf.upfronthosting.co.za> New submission from Malthe Borch: Normally, lambda arguments (positional or keyword-based) are ctx PARAM, since they're parameters. But complex (packed) arguments are ctx STORE. This is a problem for AST transformation tools that can't reliably detect the name context. ---------- components: Interpreter Core messages: 287291 nosy: malthe priority: normal severity: normal status: open title: Lambda with complex arguments is ctx STORE type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 05:10:45 2017 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Feb 2017 10:10:45 +0000 Subject: [New-bugs-announce] [issue29478] email.policy.Compat32(max_line_length=None) not as documented Message-ID: <1486548645.73.0.926739197467.issue29478@psf.upfronthosting.co.za> New submission from Martin Panter: By default, the email package turns single-line header fields into multi-line ones to try and limit the length of each line. The documentation says that setting the policy?s max_line_length attribute to None should prevent line wrapping. But this does not work: >>> from email.policy import Compat32 >>> from email.message import Message >>> from email.generator import Generator >>> from sys import stdout >>> p = Compat32(max_line_length=None) >>> m = Message(p) >>> m["Field"] = "x" * 100 >>> Generator(stdout).flatten(m) # Field is split across two lines Field: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx >>> A workaround is to specify zero instead: >>> p = Compat32(max_line_length=0) >>> Generator(stdout, policy=p).flatten(m) # All on one line Field: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Quickly looking at the code, Compat32._fold() passes max_line_length straight to Header.encode(), which is documented as using None as a placeholder for its real default value of 76. So I think the solution would be to add a special case in _fold() to call encode(maxlinelen=0) if max_line_length is None. ---------- components: email messages: 287294 nosy: barry, martin.panter, r.david.murray priority: normal severity: normal status: open title: email.policy.Compat32(max_line_length=None) not as documented type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 05:19:00 2017 From: report at bugs.python.org (song1st) Date: Wed, 08 Feb 2017 10:19:00 +0000 Subject: [New-bugs-announce] [issue29479] httplib: could not skip "ACCEPT-ENCODING" header Message-ID: <1486549140.01.0.111970837226.issue29479@psf.upfronthosting.co.za> New submission from song1st: When I tried to skip "ACCEPT-ENCODING" of header, I found the behavior was not right. I think the issue is the following two "if" in _send_request of httplib. def _send_request(self, method, url, body, headers): # Honor explicitly requested Host: and Accept-Encoding: headers. header_names = dict.fromkeys([k.lower() for k in headers]) skips = {} if 'host' in header_names: skips['skip_host'] = 1 if 'accept-encoding' in header_names: skips['skip_accept_encoding'] = 1 ---------- components: Library (Lib) messages: 287295 nosy: song1st priority: normal severity: normal status: open title: httplib: could not skip "ACCEPT-ENCODING" header type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 06:30:42 2017 From: report at bugs.python.org (Edward Ned Harvey) Date: Wed, 08 Feb 2017 11:30:42 +0000 Subject: [New-bugs-announce] [issue29480] Mac OSX Installer SSL Roots Message-ID: <1486553442.34.0.041490536597.issue29480@psf.upfronthosting.co.za> New submission from Edward Ned Harvey: I would like to suggest that the OSX installer automatically run "Install Certificates.command", or display a prompt to users saying "Run Now" during installation. Having the readme is helpful - but only after you google for 20 minutes, because of an exception you encountered. Of course nobody reads the readme during install. "I've installed python a thousand times before, I know what I'm doing." There are so many things that require SSL, and it's reasonably assumed to be functional by default. ---------- components: Installation messages: 287302 nosy: rahvee priority: normal severity: normal status: open title: Mac OSX Installer SSL Roots type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 07:53:06 2017 From: report at bugs.python.org (Guy Arad) Date: Wed, 08 Feb 2017 12:53:06 +0000 Subject: [New-bugs-announce] [issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque Message-ID: <1486558386.24.0.953871145264.issue29481@psf.upfronthosting.co.za> New submission from Guy Arad: See: - https://docs.python.org/3.6/library/typing.html#typing.Deque - https://docs.python.org/3.5/library/typing.html#typing.Deque `typing.Deque` is expected to be included in 3.6.1: https://docs.python.org/3/whatsnew/changelog.html#python-3-6-1-release-candidate-1 Please remove or specify the version in which it's going to be included. ---------- assignee: docs at python components: Documentation messages: 287313 nosy: Guy Arad, docs at python priority: normal severity: normal status: open title: 3.6.0 doc describes 3.6.1 feature - typing.Deque versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:37:43 2017 From: report at bugs.python.org (xGblankGx) Date: Wed, 08 Feb 2017 14:37:43 +0000 Subject: [New-bugs-announce] [issue29482] AddressSanitizer: attempting double-free on 0x60b000007050 Message-ID: <1486564663.6.0.319136441437.issue29482@psf.upfronthosting.co.za> New submission from xGblankGx: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGABRT, Aborted. 0x00007ffff7116418 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 Description: Heap error Short description: HeapError (10/22) Hash: fb83ab1a4cc8eeff85970c4e8a40accc.0c71313476b72a94b16ca488bd78a548 Exploitability Classification: EXPLOITABLE Explanation: The target's backtrace indicates that libc has detected a heap error or that the target was executing a heap function when it stopped. This could be due to heap corruption, passing a bad pointer to a heap function such as free(), etc. Since heap errors might include buffer overflows, use-after-free situations, etc. they are generally considered exploitable. Other tags: AbortSignal (20/22) ASAN: ...E================================================================= ==18791==ERROR: AddressSanitizer: attempting double-free on 0x60b000007050 in thread T0: #0 0x4d24f0 in __interceptor_cfree.localalias.0 asan_malloc_linux.cc.o:? #1 0x4d24f0 in ?? ??:0 #2 0x7f1f02ff8e3f in ffi_call_unix64 ??:? #3 0x7f1f02ff8e3f in ?? ??:0 #4 0x7f1f02ff88aa in ffi_call ??:? #5 0x7f1f02ff88aa in ?? ??:0 #6 0x7f1f03226311 in _call_function_pointer /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:809 #7 0x7f1f03226311 in _ctypes_callproc /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:1147 #8 0x7f1f03226311 in ?? ??:0 #9 0x7f1f03215199 in PyCFuncPtr_call /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:3870 #10 0x7f1f03215199 in ?? ??:0 #11 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #12 0x5745f0 in ?? ??:0 #13 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #14 0x7a7429 in ?? ??:0 #15 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #16 0x7995cc in ?? ??:0 #17 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #18 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #19 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #20 0x7ab4cb in ?? ??:0 #21 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #22 0x7a76f2 in ?? ??:0 #23 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #24 0x7995cc in ?? ??:0 #25 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #26 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #27 0x7a9847 in ?? ??:0 #28 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #29 0x7ac2ea in ?? ??:0 #30 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #31 0x574668 in ?? ??:0 #32 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #33 0x5749fa in ?? ??:0 #34 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #35 0x573e9b in ?? ??:0 #36 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #37 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #38 0x793369 in ?? ??:0 #39 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #40 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #41 0x7a9847 in ?? ??:0 #42 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #43 0x7ac2ea in ?? ??:0 #44 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #45 0x574668 in ?? ??:0 #46 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #47 0x5749fa in ?? ??:0 #48 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #49 0x573e9b in ?? ??:0 #50 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #51 0x66efe4 in ?? ??:0 #52 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #53 0x5745f0 in ?? ??:0 #54 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #55 0x7a7429 in ?? ??:0 #56 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #57 0x7995cc in ?? ??:0 #58 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #59 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #60 0x7a9847 in ?? ??:0 #61 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #62 0x7ac2ea in ?? ??:0 #63 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #64 0x574668 in ?? ??:0 #65 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #66 0x5749fa in ?? ??:0 #67 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #68 0x573e9b in ?? ??:0 #69 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #70 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #71 0x793369 in ?? ??:0 #72 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #73 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #74 0x7a9847 in ?? ??:0 #75 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #76 0x7ac2ea in ?? ??:0 #77 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #78 0x574668 in ?? ??:0 #79 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #80 0x5749fa in ?? ??:0 #81 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #82 0x573e9b in ?? ??:0 #83 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #84 0x66efe4 in ?? ??:0 #85 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #86 0x5745f0 in ?? ??:0 #87 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #88 0x7a7429 in ?? ??:0 #89 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #90 0x7995cc in ?? ??:0 #91 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #92 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #93 0x7a9847 in ?? ??:0 #94 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #95 0x7ac2ea in ?? ??:0 #96 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #97 0x574668 in ?? ??:0 #98 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #99 0x5749fa in ?? ??:0 #100 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #101 0x573e9b in ?? ??:0 #102 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #103 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #104 0x793369 in ?? ??:0 #105 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #106 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #107 0x7a9847 in ?? ??:0 #108 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #109 0x7ac2ea in ?? ??:0 #110 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #111 0x574668 in ?? ??:0 #112 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #113 0x5749fa in ?? ??:0 #114 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #115 0x573e9b in ?? ??:0 #116 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #117 0x66efe4 in ?? ??:0 #118 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #119 0x5745f0 in ?? ??:0 #120 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #121 0x7a7429 in ?? ??:0 #122 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #123 0x7995cc in ?? ??:0 #124 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #125 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #126 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #127 0x7ab4cb in ?? ??:0 #128 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #129 0x7a76f2 in ?? ??:0 #130 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #131 0x7995cc in ?? ??:0 #132 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #133 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #134 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #135 0x7ab4cb in ?? ??:0 #136 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #137 0x7a76f2 in ?? ??:0 #138 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #139 0x7995cc in ?? ??:0 #140 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #141 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #142 0x7a9847 in ?? ??:0 #143 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #144 0x7ac2ea in ?? ??:0 #145 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #146 0x574668 in ?? ??:0 #147 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #148 0x5749fa in ?? ??:0 #149 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #150 0x573e9b in ?? ??:0 #151 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #152 0x6713f8 in ?? ??:0 #153 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #154 0x666d8d in ?? ??:0 #155 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #156 0x5745f0 in ?? ??:0 #157 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #158 0x7a7429 in ?? ??:0 #159 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #160 0x7995cc in ?? ??:0 #161 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #162 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #163 0x7a9847 in ?? ??:0 #164 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #165 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #166 0x78e0df in ?? ??:0 #167 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #168 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #169 0x5142f5 in ?? ??:0 #170 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #171 0x512afa in ?? ??:0 #172 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #173 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #174 0x53eefd in ?? ??:0 #175 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #176 0x503d16 in ?? ??:0 #177 0x7f1f06ea582f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #178 0x7f1f06ea582f in ?? ??:0 #179 0x432548 in _start ??:? #180 0x432548 in ?? ??:0 0x60b000007050 is located 0 bytes inside of 108-byte region [0x60b000007050,0x60b0000070bc) freed by thread T0 here: #0 0x4d24f0 in __interceptor_cfree.localalias.0 asan_malloc_linux.cc.o:? #1 0x4d24f0 in ?? ??:0 #2 0x7f1f02ff8e3f in ffi_call_unix64 ??:? #3 0x7f1f02ff8e3f in ?? ??:0 #2 0x7ffc11a5271f () previously allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x7f1effe039bc in my_wcsdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:185 (discriminator 1) #3 0x7f1effe039bc in ?? ??:0 #2 0x7ffc11a5271f () SUMMARY: AddressSanitizer: double-free (/home/test/check/PythonASAN/python+0x4d24f0) ==18791==ABORTING ---------- components: Interpreter Core files: asan_malloc messages: 287316 nosy: xgblankgx priority: normal severity: normal status: open title: AddressSanitizer: attempting double-free on 0x60b000007050 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46577/asan_malloc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:40:29 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:40:29 +0000 Subject: [New-bugs-announce] [issue29483] AddressSanitizer: heap-buffer-overflow on address 0x60200000e731 Message-ID: <1486564829.78.0.80987262722.issue29483@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB: ASAN: ================================================================= ==17856==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000e731 at pc 0x0000004bc3ad bp 0x7ffe8a4e7d10 sp 0x7ffe8a4e74c0 READ of size 11 at 0x60200000e731 thread T0 #0 0x4bc3ac in __asan_memcpy ??:? #1 0x4bc3ac in ?? ??:0 #2 0x58bbb7 in PyBytes_FromStringAndSize /home/test/check/PythonASAN/Objects/bytesobject.c:123 #3 0x58bbb7 in ?? ??:0 #4 0x79987c in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:1458 (discriminator 1) #5 0x79987c in ?? ??:0 #6 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #7 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #8 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #9 0x7ab4cb in ?? ??:0 #10 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #11 0x7a76f2 in ?? ??:0 #12 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #13 0x7995cc in ?? ??:0 #14 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #15 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #16 0x7a9847 in ?? ??:0 #17 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #18 0x7ac2ea in ?? ??:0 #19 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #20 0x574668 in ?? ??:0 #21 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #22 0x5749fa in ?? ??:0 #23 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #24 0x573e9b in ?? ??:0 #25 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #26 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #27 0x793369 in ?? ??:0 #28 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #29 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #30 0x7a9847 in ?? ??:0 #31 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #32 0x7ac2ea in ?? ??:0 #33 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #34 0x574668 in ?? ??:0 #35 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #36 0x5749fa in ?? ??:0 #37 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #38 0x573e9b in ?? ??:0 #39 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #40 0x66efe4 in ?? ??:0 #41 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #42 0x5745f0 in ?? ??:0 #43 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #44 0x7a7429 in ?? ??:0 #45 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #46 0x7995cc in ?? ??:0 #47 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #48 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #49 0x7a9847 in ?? ??:0 #50 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #51 0x7ac2ea in ?? ??:0 #52 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #53 0x574668 in ?? ??:0 #54 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #55 0x5749fa in ?? ??:0 #56 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #57 0x573e9b in ?? ??:0 #58 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #59 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #60 0x793369 in ?? ??:0 #61 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #62 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #63 0x7a9847 in ?? ??:0 #64 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #65 0x7ac2ea in ?? ??:0 #66 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #67 0x574668 in ?? ??:0 #68 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #69 0x5749fa in ?? ??:0 #70 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #71 0x573e9b in ?? ??:0 #72 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #73 0x66efe4 in ?? ??:0 #74 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #75 0x5745f0 in ?? ??:0 #76 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #77 0x7a7429 in ?? ??:0 #78 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #79 0x7995cc in ?? ??:0 #80 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #81 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #82 0x7a9847 in ?? ??:0 #83 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #84 0x7ac2ea in ?? ??:0 #85 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #86 0x574668 in ?? ??:0 #87 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #88 0x5749fa in ?? ??:0 #89 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #90 0x573e9b in ?? ??:0 #91 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #92 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #93 0x793369 in ?? ??:0 #94 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #95 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #96 0x7a9847 in ?? ??:0 #97 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #98 0x7ac2ea in ?? ??:0 #99 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #100 0x574668 in ?? ??:0 #101 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #102 0x5749fa in ?? ??:0 #103 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #104 0x573e9b in ?? ??:0 #105 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #106 0x66efe4 in ?? ??:0 #107 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #108 0x5745f0 in ?? ??:0 #109 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #110 0x7a7429 in ?? ??:0 #111 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #112 0x7995cc in ?? ??:0 #113 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #114 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #115 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #116 0x7ab4cb in ?? ??:0 #117 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #118 0x7a76f2 in ?? ??:0 #119 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #120 0x7995cc in ?? ??:0 #121 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #122 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #123 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #124 0x7ab4cb in ?? ??:0 #125 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #126 0x7a76f2 in ?? ??:0 #127 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #128 0x7995cc in ?? ??:0 #129 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #130 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #131 0x7a9847 in ?? ??:0 #132 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #133 0x7ac2ea in ?? ??:0 #134 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #135 0x574668 in ?? ??:0 #136 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #137 0x5749fa in ?? ??:0 #138 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #139 0x573e9b in ?? ??:0 #140 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #141 0x6713f8 in ?? ??:0 #142 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #143 0x666d8d in ?? ??:0 #144 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #145 0x5745f0 in ?? ??:0 #146 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #147 0x7a7429 in ?? ??:0 #148 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #149 0x7995cc in ?? ??:0 #150 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #151 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #152 0x7a9847 in ?? ??:0 #153 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #154 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #155 0x78e0df in ?? ??:0 #156 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #157 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #158 0x5142f5 in ?? ??:0 #159 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #160 0x512afa in ?? ??:0 #161 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #162 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #163 0x53eefd in ?? ??:0 #164 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #165 0x503d16 in ?? ??:0 #166 0x7f7d85d5e82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #167 0x7f7d85d5e82f in ?? ??:0 #168 0x432548 in _start ??:? #169 0x432548 in ?? ??:0 0x60200000e731 is located 0 bytes to the right of 1-byte region [0x60200000e730,0x60200000e731) allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x7f7d81f8c964 in my_strdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:169 (discriminator 2) #3 0x7f7d81f8c964 in ?? ??:0 #2 0x7ffe8a4e797f () SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/test/check/PythonASAN/python+0x4bc3ac) Shadow bytes around the buggy address: 0x0c047fff9c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fff9ce0: fa fa fa fa fa fa[01]fa fa fa fd fa fa fa fd fa 0x0c047fff9cf0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d10: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d20: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d30: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==17856==ABORTING ---------- components: Interpreter Core files: bytesobject_c_123 messages: 287317 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: heap-buffer-overflow on address 0x60200000e731 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46578/bytesobject_c_123 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:41:42 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:41:42 +0000 Subject: [New-bugs-announce] [issue29484] AddressSanitizer: heap-buffer-overflow on address 0x60200000e738 Message-ID: <1486564902.18.0.325996539342.issue29484@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. PyBytes_FromStringAndSize (str=0xa76000 , size=1) at Objects/bytesobject.c:108 108 (op = characters[*str & UCHAR_MAX]) != NULL) Description: Access violation on source operand Short description: SourceAv (19/22) Hash: 4b7ecbff5972b39c26f6e0cf37443391.86c50dffa4bdc3a046d693db2d45a01e Exploitability Classification: UNKNOWN Explanation: The target crashed on an access violation at an address matching the source operand of the current instruction. This likely indicates a read access violation. Other tags: AccessViolation (21/22) ASAN: ================================================================= ==18067==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000e738 at pc 0x00000058bc2b bp 0x7ffe3c2965d0 sp 0x7ffe3c2965c8 READ of size 1 at 0x60200000e738 thread T0 #0 0x58bc2a in PyBytes_FromStringAndSize /home/test/check/PythonASAN/Objects/bytesobject.c:108 #1 0x58bc2a in ?? ??:0 #2 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #3 0x5745f0 in ?? ??:0 #4 0x677108 in slot_sq_item /home/test/check/PythonASAN/Objects/typeobject.c:5876 #5 0x677108 in ?? ??:0 #6 0x5d9714 in iter_iternext /home/test/check/PythonASAN/Objects/iterobject.c:63 #7 0x5d9714 in ?? ??:0 #8 0x571fe3 in PyIter_Next /home/test/check/PythonASAN/Objects/abstract.c:3146 #9 0x571fe3 in PySequence_Tuple /home/test/check/PythonASAN/Objects/abstract.c:1797 #10 0x571fe3 in ?? ??:0 #11 0x7ff6988bd4cf in converters_from_argtypes /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:2165 #12 0x7ff6988bd4cf in ?? ??:0 #13 0x7ff6988be677 in PyCFuncPtr_set_argtypes /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:3036 #14 0x7ff6988be677 in ?? ??:0 #15 0x63b1e7 in _PyObject_GenericSetAttrWithDict /home/test/check/PythonASAN/Objects/object.c:1152 #16 0x63b1e7 in ?? ??:0 #17 0x639d52 in PyObject_SetAttr /home/test/check/PythonASAN/Objects/object.c:932 #18 0x639d52 in ?? ??:0 #19 0x79ad9e in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:2249 #20 0x79ad9e in ?? ??:0 #21 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #22 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #23 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #24 0x7ab4cb in ?? ??:0 #25 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #26 0x7a76f2 in ?? ??:0 #27 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #28 0x7995cc in ?? ??:0 #29 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #30 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #31 0x7a9847 in ?? ??:0 #32 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #33 0x7ac2ea in ?? ??:0 #34 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #35 0x574668 in ?? ??:0 #36 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #37 0x5749fa in ?? ??:0 #38 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #39 0x573e9b in ?? ??:0 #40 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #41 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #42 0x793369 in ?? ??:0 #43 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #44 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #45 0x7a9847 in ?? ??:0 #46 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #47 0x7ac2ea in ?? ??:0 #48 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #49 0x574668 in ?? ??:0 #50 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #51 0x5749fa in ?? ??:0 #52 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #53 0x573e9b in ?? ??:0 #54 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #55 0x66efe4 in ?? ??:0 #56 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #57 0x5745f0 in ?? ??:0 #58 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #59 0x7a7429 in ?? ??:0 #60 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #61 0x7995cc in ?? ??:0 #62 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #63 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #64 0x7a9847 in ?? ??:0 #65 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #66 0x7ac2ea in ?? ??:0 #67 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #68 0x574668 in ?? ??:0 #69 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #70 0x5749fa in ?? ??:0 #71 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #72 0x573e9b in ?? ??:0 #73 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #74 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #75 0x793369 in ?? ??:0 #76 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #77 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #78 0x7a9847 in ?? ??:0 #79 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #80 0x7ac2ea in ?? ??:0 #81 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #82 0x574668 in ?? ??:0 #83 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #84 0x5749fa in ?? ??:0 #85 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #86 0x573e9b in ?? ??:0 #87 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #88 0x66efe4 in ?? ??:0 #89 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #90 0x5745f0 in ?? ??:0 #91 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #92 0x7a7429 in ?? ??:0 #93 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #94 0x7995cc in ?? ??:0 #95 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #96 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #97 0x7a9847 in ?? ??:0 #98 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #99 0x7ac2ea in ?? ??:0 #100 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #101 0x574668 in ?? ??:0 #102 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #103 0x5749fa in ?? ??:0 #104 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #105 0x573e9b in ?? ??:0 #106 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #107 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #108 0x793369 in ?? ??:0 #109 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #110 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #111 0x7a9847 in ?? ??:0 #112 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #113 0x7ac2ea in ?? ??:0 #114 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #115 0x574668 in ?? ??:0 #116 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #117 0x5749fa in ?? ??:0 #118 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #119 0x573e9b in ?? ??:0 #120 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #121 0x66efe4 in ?? ??:0 #122 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #123 0x5745f0 in ?? ??:0 #124 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #125 0x7a7429 in ?? ??:0 #126 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #127 0x7995cc in ?? ??:0 #128 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #129 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #130 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #131 0x7ab4cb in ?? ??:0 #132 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #133 0x7a76f2 in ?? ??:0 #134 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #135 0x7995cc in ?? ??:0 #136 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #137 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #138 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #139 0x7ab4cb in ?? ??:0 #140 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #141 0x7a76f2 in ?? ??:0 #142 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #143 0x7995cc in ?? ??:0 #144 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #145 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #146 0x7a9847 in ?? ??:0 #147 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #148 0x7ac2ea in ?? ??:0 #149 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #150 0x574668 in ?? ??:0 #151 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #152 0x5749fa in ?? ??:0 #153 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #154 0x573e9b in ?? ??:0 #155 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #156 0x6713f8 in ?? ??:0 #157 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #158 0x666d8d in ?? ??:0 #159 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #160 0x5745f0 in ?? ??:0 #161 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #162 0x7a7429 in ?? ??:0 #163 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #164 0x7995cc in ?? ??:0 #165 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #166 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #167 0x7a9847 in ?? ??:0 #168 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #169 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #170 0x78e0df in ?? ??:0 #171 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #172 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #173 0x5142f5 in ?? ??:0 #174 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #175 0x512afa in ?? ??:0 #176 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #177 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #178 0x53eefd in ?? ??:0 #179 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #180 0x503d16 in ?? ??:0 #181 0x7ff69c1fc82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #182 0x7ff69c1fc82f in ?? ??:0 #183 0x432548 in _start ??:? #184 0x432548 in ?? ??:0 0x60200000e738 is located 0 bytes to the right of 8-byte region [0x60200000e730,0x60200000e738) allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x7ff6984359bc in my_wcsdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:185 (discriminator 1) #3 0x7ff6984359bc in ?? ??:0 #2 0x7ffe3c29661f () SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/test/check/PythonASAN/python+0x58bc2a) Shadow bytes around the buggy address: 0x0c047fff9c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fff9ce0: fa fa fa fa fa fa 00[fa]fa fa fd fa fa fa fd fa 0x0c047fff9cf0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d10: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d20: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d30: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==18067==ABORTING ---------- components: Interpreter Core files: bytobj_108 messages: 287318 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: heap-buffer-overflow on address 0x60200000e738 versions: Python 3.6 Added file: http://bugs.python.org/file46579/bytobj_108 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:42:58 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:42:58 +0000 Subject: [New-bugs-announce] [issue29485] AddressSanitizer: SEGV on unknown address 0x7fab556df550 Message-ID: <1486564978.33.0.577417713514.issue29485@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. z_get (ptr=0x7ffff5bba5d8, size=8) at /home/test/check/PythonGDB/Modules/_ctypes/cfield.c:1336 1336 if (*(void **)ptr) { Description: Access violation on source operand Short description: SourceAv (19/22) Hash: 3930661c9a0f4c1f31bb4f2341bca47f.d4e21449248c6102834e8b566f6b2ac9 Exploitability Classification: UNKNOWN Explanation: The target crashed on an access violation at an address matching the source operand of the current instruction. This likely indicates a read access violation. Other tags: AccessViolation (21/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18885==ERROR: AddressSanitizer: SEGV on unknown address 0x7fab556df550 (pc 0x7fab558d0cd1 bp 0x7fab5a4b0b90 sp 0x7ffc9cbcc220 T0) #0 0x7fab558d0cd0 in z_get /home/test/check/PythonASAN/Modules/_ctypes/cfield.c:1336 #1 0x7fab558d0cd0 in ?? ??:0 #2 0x63ac07 in _PyObject_GenericGetAttrWithDict /home/test/check/PythonASAN/Objects/object.c:1060 #3 0x63ac07 in ?? ??:0 #4 0x7966cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:2815 (discriminator 1) #5 0x7966cc in ?? ??:0 #6 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #7 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #8 0x7a9847 in ?? ??:0 #9 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #10 0x7ab648 in ?? ??:0 #11 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #12 0x7a76f2 in ?? ??:0 #13 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #14 0x7995cc in ?? ??:0 #15 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #16 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #17 0x7a9847 in ?? ??:0 #18 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #19 0x7ac2ea in ?? ??:0 #20 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #21 0x574668 in ?? ??:0 #22 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #23 0x5749fa in ?? ??:0 #24 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #25 0x573e9b in ?? ??:0 #26 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #27 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #28 0x793369 in ?? ??:0 #29 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #30 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #31 0x7a9847 in ?? ??:0 #32 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #33 0x7ac2ea in ?? ??:0 #34 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #35 0x574668 in ?? ??:0 #36 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #37 0x5749fa in ?? ??:0 #38 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #39 0x573e9b in ?? ??:0 #40 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #41 0x66efe4 in ?? ??:0 #42 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #43 0x5745f0 in ?? ??:0 #44 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #45 0x7a7429 in ?? ??:0 #46 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #47 0x7995cc in ?? ??:0 #48 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #49 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #50 0x7a9847 in ?? ??:0 #51 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #52 0x7ac2ea in ?? ??:0 #53 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #54 0x574668 in ?? ??:0 #55 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #56 0x5749fa in ?? ??:0 #57 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #58 0x573e9b in ?? ??:0 #59 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #60 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #61 0x793369 in ?? ??:0 #62 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #63 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #64 0x7a9847 in ?? ??:0 #65 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #66 0x7ac2ea in ?? ??:0 #67 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #68 0x574668 in ?? ??:0 #69 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #70 0x5749fa in ?? ??:0 #71 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #72 0x573e9b in ?? ??:0 #73 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #74 0x66efe4 in ?? ??:0 #75 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #76 0x5745f0 in ?? ??:0 #77 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #78 0x7a7429 in ?? ??:0 #79 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #80 0x7995cc in ?? ??:0 #81 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #82 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #83 0x7a9847 in ?? ??:0 #84 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #85 0x7ac2ea in ?? ??:0 #86 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #87 0x574668 in ?? ??:0 #88 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #89 0x5749fa in ?? ??:0 #90 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #91 0x573e9b in ?? ??:0 #92 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #93 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #94 0x793369 in ?? ??:0 #95 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #96 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #97 0x7a9847 in ?? ??:0 #98 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #99 0x7ac2ea in ?? ??:0 #100 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #101 0x574668 in ?? ??:0 #102 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #103 0x5749fa in ?? ??:0 #104 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #105 0x573e9b in ?? ??:0 #106 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #107 0x66efe4 in ?? ??:0 #108 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #109 0x5745f0 in ?? ??:0 #110 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #111 0x7a7429 in ?? ??:0 #112 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #113 0x7995cc in ?? ??:0 #114 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #115 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #116 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #117 0x7ab4cb in ?? ??:0 #118 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #119 0x7a76f2 in ?? ??:0 #120 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #121 0x7995cc in ?? ??:0 #122 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #123 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #124 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #125 0x7ab4cb in ?? ??:0 #126 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #127 0x7a76f2 in ?? ??:0 #128 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #129 0x7995cc in ?? ??:0 #130 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #131 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #132 0x7a9847 in ?? ??:0 #133 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #134 0x7ac2ea in ?? ??:0 #135 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #136 0x574668 in ?? ??:0 #137 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #138 0x5749fa in ?? ??:0 #139 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #140 0x573e9b in ?? ??:0 #141 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #142 0x6713f8 in ?? ??:0 #143 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #144 0x666d8d in ?? ??:0 #145 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #146 0x5745f0 in ?? ??:0 #147 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #148 0x7a7429 in ?? ??:0 #149 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #150 0x7995cc in ?? ??:0 #151 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #152 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #153 0x7a9847 in ?? ??:0 #154 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #155 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #156 0x78e0df in ?? ??:0 #157 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #158 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #159 0x5142f5 in ?? ??:0 #160 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #161 0x512afa in ?? ??:0 #162 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #163 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #164 0x53eefd in ?? ??:0 #165 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #166 0x503d16 in ?? ??:0 #167 0x7fab5921b82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #168 0x7fab5921b82f in ?? ??:0 #169 0x432548 in _start ??:? #170 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x36cd0) ==18885==ABORTING ---------- components: Interpreter Core files: cfield_1336 messages: 287319 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x7fab556df550 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46580/cfield_1336 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:44:02 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:44:02 +0000 Subject: [New-bugs-announce] [issue29486] AddressSanitizer: SEGV on unknown address 0x7f16f88e3560 Message-ID: <1486565042.15.0.952325483441.issue29486@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGBUS, Bus error. 0x00007ffff63a6dfe in i_set (ptr=0x8007f5b3f5e8, value=, size=4) at /home/test/check/PythonGDB/Modules/_ctypes/cfield.c:650 650 x = SET(int, x, val, size); Description: Access violation Short description: AccessViolation (21/22) Hash: 0e6533f2dc6ec45bf8aced4adaa8169a.5ae343e4a8ceeca018e7fc78f552033e Exploitability Classification: UNKNOWN Explanation: The target crashed due to an access violation but there is not enough additional information available to determine exploitability. ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18660==ERROR: AddressSanitizer: SEGV on unknown address 0x7f16f88e3560 (pc 0x7f0ef90f6e68 bp 0x619000035c98 sp 0x7ffe7b44e2e0 T0) #0 0x7f0ef90f6e67 in i_set /home/test/check/PythonASAN/Modules/_ctypes/cfield.c:651 #1 0x7f0ef90f6e67 in ?? ??:0 #2 0x7f0ef90da8ea in PyCData_set /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:2916 #3 0x7f0ef90da8ea in ?? ??:0 #4 0x7f0ef90f5470 in PyCField_set /home/test/check/PythonASAN/Modules/_ctypes/cfield.c:216 #5 0x7f0ef90f5470 in ?? ??:0 #6 0x63b1e7 in _PyObject_GenericSetAttrWithDict /home/test/check/PythonASAN/Objects/object.c:1152 #7 0x63b1e7 in ?? ??:0 #8 0x639d52 in PyObject_SetAttr /home/test/check/PythonASAN/Objects/object.c:932 #9 0x639d52 in ?? ??:0 #10 0x79ad9e in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:2249 #11 0x79ad9e in ?? ??:0 #12 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #13 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #14 0x7a9847 in ?? ??:0 #15 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #16 0x7ab648 in ?? ??:0 #17 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #18 0x7a76f2 in ?? ??:0 #19 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #20 0x7995cc in ?? ??:0 #21 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #22 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #23 0x7a9847 in ?? ??:0 #24 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #25 0x7ac2ea in ?? ??:0 #26 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #27 0x574668 in ?? ??:0 #28 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #29 0x5749fa in ?? ??:0 #30 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #31 0x573e9b in ?? ??:0 #32 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #33 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #34 0x793369 in ?? ??:0 #35 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #36 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #37 0x7a9847 in ?? ??:0 #38 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #39 0x7ac2ea in ?? ??:0 #40 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #41 0x574668 in ?? ??:0 #42 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #43 0x5749fa in ?? ??:0 #44 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #45 0x573e9b in ?? ??:0 #46 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #47 0x66efe4 in ?? ??:0 #48 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #49 0x5745f0 in ?? ??:0 #50 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #51 0x7a7429 in ?? ??:0 #52 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #53 0x7995cc in ?? ??:0 #54 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #55 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #56 0x7a9847 in ?? ??:0 #57 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #58 0x7ac2ea in ?? ??:0 #59 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #60 0x574668 in ?? ??:0 #61 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #62 0x5749fa in ?? ??:0 #63 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #64 0x573e9b in ?? ??:0 #65 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #66 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #67 0x793369 in ?? ??:0 #68 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #69 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #70 0x7a9847 in ?? ??:0 #71 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #72 0x7ac2ea in ?? ??:0 #73 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #74 0x574668 in ?? ??:0 #75 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #76 0x5749fa in ?? ??:0 #77 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #78 0x573e9b in ?? ??:0 #79 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #80 0x66efe4 in ?? ??:0 #81 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #82 0x5745f0 in ?? ??:0 #83 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #84 0x7a7429 in ?? ??:0 #85 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #86 0x7995cc in ?? ??:0 #87 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #88 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #89 0x7a9847 in ?? ??:0 #90 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #91 0x7ac2ea in ?? ??:0 #92 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #93 0x574668 in ?? ??:0 #94 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #95 0x5749fa in ?? ??:0 #96 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #97 0x573e9b in ?? ??:0 #98 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #99 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #100 0x793369 in ?? ??:0 #101 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #102 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #103 0x7a9847 in ?? ??:0 #104 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #105 0x7ac2ea in ?? ??:0 #106 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #107 0x574668 in ?? ??:0 #108 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #109 0x5749fa in ?? ??:0 #110 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #111 0x573e9b in ?? ??:0 #112 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #113 0x66efe4 in ?? ??:0 #114 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #115 0x5745f0 in ?? ??:0 #116 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #117 0x7a7429 in ?? ??:0 #118 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #119 0x7995cc in ?? ??:0 #120 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #121 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #122 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #123 0x7ab4cb in ?? ??:0 #124 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #125 0x7a76f2 in ?? ??:0 #126 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #127 0x7995cc in ?? ??:0 #128 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #129 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #130 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #131 0x7ab4cb in ?? ??:0 #132 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #133 0x7a76f2 in ?? ??:0 #134 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #135 0x7995cc in ?? ??:0 #136 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #137 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #138 0x7a9847 in ?? ??:0 #139 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #140 0x7ac2ea in ?? ??:0 #141 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #142 0x574668 in ?? ??:0 #143 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #144 0x5749fa in ?? ??:0 #145 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #146 0x573e9b in ?? ??:0 #147 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #148 0x6713f8 in ?? ??:0 #149 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #150 0x666d8d in ?? ??:0 #151 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #152 0x5745f0 in ?? ??:0 #153 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #154 0x7a7429 in ?? ??:0 #155 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #156 0x7995cc in ?? ??:0 #157 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #158 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #159 0x7a9847 in ?? ??:0 #160 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #161 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #162 0x78e0df in ?? ??:0 #163 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #164 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #165 0x5142f5 in ?? ??:0 #166 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #167 0x512afa in ?? ??:0 #168 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #169 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #170 0x53eefd in ?? ??:0 #171 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #172 0x503d16 in ?? ??:0 #173 0x7f0efc49282f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #174 0x7f0efc49282f in ?? ??:0 #175 0x432548 in _start ??:? #176 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x34e67) ==18660==ABORTING ---------- components: Interpreter Core files: cfield_651 messages: 287320 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x7f16f88e3560 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46581/cfield_651 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:44:48 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:44:48 +0000 Subject: [New-bugs-announce] [issue29487] AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 Message-ID: <1486565088.06.0.199584603629.issue29487@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Inferior 1 (process 19362) exited with code 01] ASAN: ================================================================= ==18038==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 at pc 0x7fbe64d4ef87 bp 0x7ffdd65d7190 sp 0x7ffdd65d7188 READ of size 4 at 0x60200000e734 thread T0 #0 0x7fbe64d4ef86 in i_get /home/test/check/PythonASAN/Modules/_ctypes/cfield.c:675 #1 0x7fbe64d4ef86 in ?? ??:0 #2 0x7fbe64d40dca in Pointer_subscript /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:5026 (discriminator 1) #3 0x7fbe64d40dca in ?? ??:0 #4 0x79987c in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:1458 (discriminator 1) #5 0x79987c in ?? ??:0 #6 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #7 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #8 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #9 0x7ab4cb in ?? ??:0 #10 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #11 0x7a76f2 in ?? ??:0 #12 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #13 0x7995cc in ?? ??:0 #14 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #15 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #16 0x7a9847 in ?? ??:0 #17 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #18 0x7ac2ea in ?? ??:0 #19 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #20 0x574668 in ?? ??:0 #21 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #22 0x5749fa in ?? ??:0 #23 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #24 0x573e9b in ?? ??:0 #25 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #26 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #27 0x793369 in ?? ??:0 #28 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #29 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #30 0x7a9847 in ?? ??:0 #31 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #32 0x7ac2ea in ?? ??:0 #33 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #34 0x574668 in ?? ??:0 #35 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #36 0x5749fa in ?? ??:0 #37 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #38 0x573e9b in ?? ??:0 #39 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #40 0x66efe4 in ?? ??:0 #41 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #42 0x5745f0 in ?? ??:0 #43 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #44 0x7a7429 in ?? ??:0 #45 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #46 0x7995cc in ?? ??:0 #47 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #48 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #49 0x7a9847 in ?? ??:0 #50 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #51 0x7ac2ea in ?? ??:0 #52 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #53 0x574668 in ?? ??:0 #54 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #55 0x5749fa in ?? ??:0 #56 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #57 0x573e9b in ?? ??:0 #58 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #59 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #60 0x793369 in ?? ??:0 #61 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #62 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #63 0x7a9847 in ?? ??:0 #64 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #65 0x7ac2ea in ?? ??:0 #66 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #67 0x574668 in ?? ??:0 #68 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #69 0x5749fa in ?? ??:0 #70 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #71 0x573e9b in ?? ??:0 #72 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #73 0x66efe4 in ?? ??:0 #74 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #75 0x5745f0 in ?? ??:0 #76 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #77 0x7a7429 in ?? ??:0 #78 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #79 0x7995cc in ?? ??:0 #80 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #81 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #82 0x7a9847 in ?? ??:0 #83 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #84 0x7ac2ea in ?? ??:0 #85 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #86 0x574668 in ?? ??:0 #87 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #88 0x5749fa in ?? ??:0 #89 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #90 0x573e9b in ?? ??:0 #91 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #92 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #93 0x793369 in ?? ??:0 #94 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #95 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #96 0x7a9847 in ?? ??:0 #97 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #98 0x7ac2ea in ?? ??:0 #99 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #100 0x574668 in ?? ??:0 #101 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #102 0x5749fa in ?? ??:0 #103 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #104 0x573e9b in ?? ??:0 #105 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #106 0x66efe4 in ?? ??:0 #107 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #108 0x5745f0 in ?? ??:0 #109 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #110 0x7a7429 in ?? ??:0 #111 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #112 0x7995cc in ?? ??:0 #113 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #114 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #115 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #116 0x7ab4cb in ?? ??:0 #117 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #118 0x7a76f2 in ?? ??:0 #119 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #120 0x7995cc in ?? ??:0 #121 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #122 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #123 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #124 0x7ab4cb in ?? ??:0 #125 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #126 0x7a76f2 in ?? ??:0 #127 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #128 0x7995cc in ?? ??:0 #129 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #130 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #131 0x7a9847 in ?? ??:0 #132 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #133 0x7ac2ea in ?? ??:0 #134 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #135 0x574668 in ?? ??:0 #136 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #137 0x5749fa in ?? ??:0 #138 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #139 0x573e9b in ?? ??:0 #140 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #141 0x6713f8 in ?? ??:0 #142 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #143 0x666d8d in ?? ??:0 #144 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #145 0x5745f0 in ?? ??:0 #146 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #147 0x7a7429 in ?? ??:0 #148 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #149 0x7995cc in ?? ??:0 #150 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #151 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #152 0x7a9847 in ?? ??:0 #153 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #154 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #155 0x78e0df in ?? ??:0 #156 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #157 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #158 0x5142f5 in ?? ??:0 #159 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #160 0x512afa in ?? ??:0 #161 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #162 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #163 0x53eefd in ?? ??:0 #164 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #165 0x503d16 in ?? ??:0 #166 0x7fbe686a582f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #167 0x7fbe686a582f in ?? ??:0 #168 0x432548 in _start ??:? #169 0x432548 in ?? ??:0 0x60200000e734 is located 0 bytes to the right of 4-byte region [0x60200000e730,0x60200000e734) allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x7fbe648cc9bc in my_wcsdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:185 (discriminator 1) #3 0x7fbe648cc9bc in ?? ??:0 #2 0x7ffdd65d6e3f () SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x34f86) Shadow bytes around the buggy address: 0x0c047fff9c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fff9ce0: fa fa fa fa fa fa[04]fa fa fa fd fa fa fa fd fa 0x0c047fff9cf0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d10: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d20: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d30: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==18038==ABORTING ---------- components: Interpreter Core files: cfield_675 messages: 287321 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46582/cfield_675 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:45:37 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:45:37 +0000 Subject: [New-bugs-announce] [issue29488] AddressSanitizer: SEGV on unknown address 0x0001a5525c1b Message-ID: <1486565137.31.0.431748723797.issue29488@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff639c455 in PyCData_clear (self=0x7ffff5b3f510) at /home/test/check/PythonGDB/Modules/_ctypes/_ctypes.c:2497 2497 Py_CLEAR(self->b_objects); Description: Access violation on destination operand Short description: DestAv (8/22) Hash: 8dc538f2a05876e51d4aacf57c47935b.6a0f7d54d57adbe0b04a497a3ee9c96c Exploitability Classification: EXPLOITABLE Explanation: The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control the write address and/or value. Other tags: AccessViolation (21/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18570==ERROR: AddressSanitizer: SEGV on unknown address 0x0001a5525c1b (pc 0x7f922b0d9c62 bp 0x7f922b0d9c20 sp 0x7ffc440acf10 T0) #0 0x7f922b0d9c61 in PyCData_clear /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:2497 (discriminator 3) #1 0x7f922b0d9c61 in PyCData_dealloc /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:2509 (discriminator 3) #2 0x7f922b0d9c61 in ?? ??:0 #3 0x65d51a in subtype_dealloc /home/test/check/PythonASAN/Objects/typeobject.c:1222 #4 0x65d51a in ?? ??:0 #5 0x60fb27 in free_keys_object /home/test/check/PythonASAN/Objects/dictobject.c:561 (discriminator 5) #6 0x60fb27 in ?? ??:0 #7 0x6163fa in dict_dealloc /home/test/check/PythonASAN/Objects/dictobject.c:1933 (discriminator 1) #8 0x6163fa in ?? ??:0 #9 0x7f922b0d9ca8 in PyCData_clear /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:2497 (discriminator 5) #10 0x7f922b0d9ca8 in PyCData_dealloc /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:2509 (discriminator 5) #11 0x7f922b0d9ca8 in ?? ??:0 #12 0x65d51a in subtype_dealloc /home/test/check/PythonASAN/Objects/typeobject.c:1222 #13 0x65d51a in ?? ??:0 #14 0x5d10da in frame_dealloc /home/test/check/PythonASAN/Objects/frameobject.c:423 (discriminator 5) #15 0x5d10da in ?? ??:0 #16 0x7a98ca in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4130 (discriminator 3) #17 0x7a98ca in ?? ??:0 #18 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #19 0x7ab648 in ?? ??:0 #20 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #21 0x7a76f2 in ?? ??:0 #22 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #23 0x7995cc in ?? ??:0 #24 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #25 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #26 0x7a9847 in ?? ??:0 #27 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #28 0x7ac2ea in ?? ??:0 #29 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #30 0x574668 in ?? ??:0 #31 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #32 0x5749fa in ?? ??:0 #33 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #34 0x573e9b in ?? ??:0 #35 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #36 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #37 0x793369 in ?? ??:0 #38 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #39 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #40 0x7a9847 in ?? ??:0 #41 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #42 0x7ac2ea in ?? ??:0 #43 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #44 0x574668 in ?? ??:0 #45 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #46 0x5749fa in ?? ??:0 #47 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #48 0x573e9b in ?? ??:0 #49 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #50 0x66efe4 in ?? ??:0 #51 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #52 0x5745f0 in ?? ??:0 #53 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #54 0x7a7429 in ?? ??:0 #55 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #56 0x7995cc in ?? ??:0 #57 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #58 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #59 0x7a9847 in ?? ??:0 #60 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #61 0x7ac2ea in ?? ??:0 #62 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #63 0x574668 in ?? ??:0 #64 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #65 0x5749fa in ?? ??:0 #66 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #67 0x573e9b in ?? ??:0 #68 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #69 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #70 0x793369 in ?? ??:0 #71 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #72 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #73 0x7a9847 in ?? ??:0 #74 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #75 0x7ac2ea in ?? ??:0 #76 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #77 0x574668 in ?? ??:0 #78 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #79 0x5749fa in ?? ??:0 #80 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #81 0x573e9b in ?? ??:0 #82 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #83 0x66efe4 in ?? ??:0 #84 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #85 0x5745f0 in ?? ??:0 #86 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #87 0x7a7429 in ?? ??:0 #88 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #89 0x7995cc in ?? ??:0 #90 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #91 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #92 0x7a9847 in ?? ??:0 #93 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #94 0x7ac2ea in ?? ??:0 #95 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #96 0x574668 in ?? ??:0 #97 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #98 0x5749fa in ?? ??:0 #99 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #100 0x573e9b in ?? ??:0 #101 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #102 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #103 0x793369 in ?? ??:0 #104 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #105 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #106 0x7a9847 in ?? ??:0 #107 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #108 0x7ac2ea in ?? ??:0 #109 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #110 0x574668 in ?? ??:0 #111 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #112 0x5749fa in ?? ??:0 #113 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #114 0x573e9b in ?? ??:0 #115 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #116 0x66efe4 in ?? ??:0 #117 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #118 0x5745f0 in ?? ??:0 #119 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #120 0x7a7429 in ?? ??:0 #121 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #122 0x7995cc in ?? ??:0 #123 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #124 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #125 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #126 0x7ab4cb in ?? ??:0 #127 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #128 0x7a76f2 in ?? ??:0 #129 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #130 0x7995cc in ?? ??:0 #131 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #132 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #133 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #134 0x7ab4cb in ?? ??:0 #135 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #136 0x7a76f2 in ?? ??:0 #137 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #138 0x7995cc in ?? ??:0 #139 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #140 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #141 0x7a9847 in ?? ??:0 #142 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #143 0x7ac2ea in ?? ??:0 #144 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #145 0x574668 in ?? ??:0 #146 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #147 0x5749fa in ?? ??:0 #148 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #149 0x573e9b in ?? ??:0 #150 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #151 0x6713f8 in ?? ??:0 #152 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #153 0x666d8d in ?? ??:0 #154 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #155 0x5745f0 in ?? ??:0 #156 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #157 0x7a7429 in ?? ??:0 #158 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #159 0x7995cc in ?? ??:0 #160 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #161 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #162 0x7a9847 in ?? ??:0 #163 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #164 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #165 0x78e0df in ?? ??:0 #166 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #167 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #168 0x5142f5 in ?? ??:0 #169 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #170 0x512afa in ?? ??:0 #171 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #172 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #173 0x53eefd in ?? ??:0 #174 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #175 0x503d16 in ?? ??:0 #176 0x7f922e50882f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #177 0x7f922e50882f in ?? ??:0 #178 0x432548 in _start ??:? #179 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x17c61) ==18570==ABORTING ---------- components: Interpreter Core files: ctypes_2497 messages: 287322 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x0001a5525c1b type: security versions: Python 3.6 Added file: http://bugs.python.org/file46583/ctypes_2497 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:46:24 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:46:24 +0000 Subject: [New-bugs-announce] [issue29489] AddressSanitizer: SEGV on unknown address 0x7f4a36c604d0 Message-ID: <1486565184.6.0.709487123747.issue29489@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5d87282 in Pointer_item (index=32767, myself=0x7ffff5b3b620) at /home/test/check/PythonGDB/Modules/_ctypes/_ctypes.c:4748 4748 if (*(void **)self->b_ptr == NULL) { Description: Access violation on destination operand Short description: DestAv (8/22) Hash: 6d733dd19a93baf3031238df7085b89d.f931e2f4bcacefcb07769ddcf0b1360f Exploitability Classification: EXPLOITABLE Explanation: The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control the write address and/or value. Other tags: AccessViolation (21/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18357==ERROR: AddressSanitizer: SEGV on unknown address 0x7f4a36c604d0 (pc 0x7f4a36e40562 bp 0x7ffc8c278530 sp 0x7ffc8c278060 T0) #0 0x7f4a36e40561 in Pointer_item /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:4748 #1 0x7f4a36e40561 in ?? ??:0 #2 0x79987c in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:1458 (discriminator 1) #3 0x79987c in ?? ??:0 #4 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #5 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #6 0x7a9847 in ?? ??:0 #7 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #8 0x7ab648 in ?? ??:0 #9 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #10 0x7a76f2 in ?? ??:0 #11 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #12 0x7995cc in ?? ??:0 #13 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #14 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #15 0x7a9847 in ?? ??:0 #16 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #17 0x7ac2ea in ?? ??:0 #18 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #19 0x574668 in ?? ??:0 #20 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #21 0x5749fa in ?? ??:0 #22 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #23 0x573e9b in ?? ??:0 #24 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #25 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #26 0x793369 in ?? ??:0 #27 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #28 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #29 0x7a9847 in ?? ??:0 #30 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #31 0x7ac2ea in ?? ??:0 #32 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #33 0x574668 in ?? ??:0 #34 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #35 0x5749fa in ?? ??:0 #36 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #37 0x573e9b in ?? ??:0 #38 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #39 0x66efe4 in ?? ??:0 #40 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #41 0x5745f0 in ?? ??:0 #42 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #43 0x7a7429 in ?? ??:0 #44 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #45 0x7995cc in ?? ??:0 #46 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #47 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #48 0x7a9847 in ?? ??:0 #49 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #50 0x7ac2ea in ?? ??:0 #51 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #52 0x574668 in ?? ??:0 #53 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #54 0x5749fa in ?? ??:0 #55 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #56 0x573e9b in ?? ??:0 #57 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #58 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #59 0x793369 in ?? ??:0 #60 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #61 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #62 0x7a9847 in ?? ??:0 #63 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #64 0x7ac2ea in ?? ??:0 #65 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #66 0x574668 in ?? ??:0 #67 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #68 0x5749fa in ?? ??:0 #69 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #70 0x573e9b in ?? ??:0 #71 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #72 0x66efe4 in ?? ??:0 #73 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #74 0x5745f0 in ?? ??:0 #75 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #76 0x7a7429 in ?? ??:0 #77 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #78 0x7995cc in ?? ??:0 #79 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #80 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #81 0x7a9847 in ?? ??:0 #82 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #83 0x7ac2ea in ?? ??:0 #84 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #85 0x574668 in ?? ??:0 #86 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #87 0x5749fa in ?? ??:0 #88 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #89 0x573e9b in ?? ??:0 #90 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #91 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #92 0x793369 in ?? ??:0 #93 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #94 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #95 0x7a9847 in ?? ??:0 #96 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #97 0x7ac2ea in ?? ??:0 #98 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #99 0x574668 in ?? ??:0 #100 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #101 0x5749fa in ?? ??:0 #102 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #103 0x573e9b in ?? ??:0 #104 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #105 0x66efe4 in ?? ??:0 #106 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #107 0x5745f0 in ?? ??:0 #108 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #109 0x7a7429 in ?? ??:0 #110 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #111 0x7995cc in ?? ??:0 #112 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #113 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #114 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #115 0x7ab4cb in ?? ??:0 #116 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #117 0x7a76f2 in ?? ??:0 #118 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #119 0x7995cc in ?? ??:0 #120 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #121 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #122 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #123 0x7ab4cb in ?? ??:0 #124 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #125 0x7a76f2 in ?? ??:0 #126 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #127 0x7995cc in ?? ??:0 #128 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #129 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #130 0x7a9847 in ?? ??:0 #131 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #132 0x7ac2ea in ?? ??:0 #133 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #134 0x574668 in ?? ??:0 #135 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #136 0x5749fa in ?? ??:0 #137 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #138 0x573e9b in ?? ??:0 #139 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #140 0x6713f8 in ?? ??:0 #141 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #142 0x666d8d in ?? ??:0 #143 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #144 0x5745f0 in ?? ??:0 #145 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #146 0x7a7429 in ?? ??:0 #147 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #148 0x7995cc in ?? ??:0 #149 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #150 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #151 0x7a9847 in ?? ??:0 #152 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #153 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #154 0x78e0df in ?? ??:0 #155 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #156 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #157 0x5142f5 in ?? ??:0 #158 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #159 0x512afa in ?? ??:0 #160 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #161 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #162 0x53eefd in ?? ??:0 #163 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #164 0x503d16 in ?? ??:0 #165 0x7f4a3a79082f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #166 0x7f4a3a79082f in ?? ??:0 #167 0x432548 in _start ??:? #168 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x26561) ==18357==ABORTING ---------- components: Interpreter Core files: ctypes_4748 messages: 287323 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x7f4a36c604d0 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46584/ctypes_4748 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:47:36 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:47:36 +0000 Subject: [New-bugs-announce] [issue29490] AddressSanitizer: heap-buffer-overflow on address 0x60200000e72f Message-ID: <1486565256.82.0.439128753451.issue29490@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Inferior 1 (process 19391) exited with code 01] ASAN: ================================================================= ==17908==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000e72f at pc 0x7f191d68154b bp 0x7ffd5c1c7e60 sp 0x7ffd5c1c7e58 READ of size 1 at 0x60200000e72f thread T0 #0 0x7f191d68154a in Pointer_subscript /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:4992 #1 0x7f191d68154a in ?? ??:0 #2 0x79987c in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:1458 (discriminator 1) #3 0x79987c in ?? ??:0 #4 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #5 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #6 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #7 0x7ab4cb in ?? ??:0 #8 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #9 0x7a76f2 in ?? ??:0 #10 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #11 0x7995cc in ?? ??:0 #12 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #13 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #14 0x7a9847 in ?? ??:0 #15 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #16 0x7ac2ea in ?? ??:0 #17 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #18 0x574668 in ?? ??:0 #19 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #20 0x5749fa in ?? ??:0 #21 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #22 0x573e9b in ?? ??:0 #23 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #24 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #25 0x793369 in ?? ??:0 #26 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #27 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #28 0x7a9847 in ?? ??:0 #29 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #30 0x7ac2ea in ?? ??:0 #31 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #32 0x574668 in ?? ??:0 #33 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #34 0x5749fa in ?? ??:0 #35 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #36 0x573e9b in ?? ??:0 #37 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #38 0x66efe4 in ?? ??:0 #39 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #40 0x5745f0 in ?? ??:0 #41 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #42 0x7a7429 in ?? ??:0 #43 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #44 0x7995cc in ?? ??:0 #45 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #46 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #47 0x7a9847 in ?? ??:0 #48 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #49 0x7ac2ea in ?? ??:0 #50 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #51 0x574668 in ?? ??:0 #52 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #53 0x5749fa in ?? ??:0 #54 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #55 0x573e9b in ?? ??:0 #56 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #57 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #58 0x793369 in ?? ??:0 #59 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #60 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #61 0x7a9847 in ?? ??:0 #62 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #63 0x7ac2ea in ?? ??:0 #64 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #65 0x574668 in ?? ??:0 #66 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #67 0x5749fa in ?? ??:0 #68 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #69 0x573e9b in ?? ??:0 #70 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #71 0x66efe4 in ?? ??:0 #72 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #73 0x5745f0 in ?? ??:0 #74 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #75 0x7a7429 in ?? ??:0 #76 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #77 0x7995cc in ?? ??:0 #78 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #79 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #80 0x7a9847 in ?? ??:0 #81 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #82 0x7ac2ea in ?? ??:0 #83 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #84 0x574668 in ?? ??:0 #85 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #86 0x5749fa in ?? ??:0 #87 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #88 0x573e9b in ?? ??:0 #89 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #90 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #91 0x793369 in ?? ??:0 #92 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #93 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #94 0x7a9847 in ?? ??:0 #95 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #96 0x7ac2ea in ?? ??:0 #97 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #98 0x574668 in ?? ??:0 #99 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #100 0x5749fa in ?? ??:0 #101 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #102 0x573e9b in ?? ??:0 #103 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #104 0x66efe4 in ?? ??:0 #105 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #106 0x5745f0 in ?? ??:0 #107 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #108 0x7a7429 in ?? ??:0 #109 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #110 0x7995cc in ?? ??:0 #111 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #112 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #113 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #114 0x7ab4cb in ?? ??:0 #115 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #116 0x7a76f2 in ?? ??:0 #117 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #118 0x7995cc in ?? ??:0 #119 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #120 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #121 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #122 0x7ab4cb in ?? ??:0 #123 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #124 0x7a76f2 in ?? ??:0 #125 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #126 0x7995cc in ?? ??:0 #127 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #128 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #129 0x7a9847 in ?? ??:0 #130 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #131 0x7ac2ea in ?? ??:0 #132 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #133 0x574668 in ?? ??:0 #134 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #135 0x5749fa in ?? ??:0 #136 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #137 0x573e9b in ?? ??:0 #138 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #139 0x6713f8 in ?? ??:0 #140 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #141 0x666d8d in ?? ??:0 #142 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #143 0x5745f0 in ?? ??:0 #144 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #145 0x7a7429 in ?? ??:0 #146 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #147 0x7995cc in ?? ??:0 #148 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #149 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #150 0x7a9847 in ?? ??:0 #151 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #152 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #153 0x78e0df in ?? ??:0 #154 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #155 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #156 0x5142f5 in ?? ??:0 #157 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #158 0x512afa in ?? ??:0 #159 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #160 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #161 0x53eefd in ?? ??:0 #162 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #163 0x503d16 in ?? ??:0 #164 0x7f1920fba82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #165 0x7f1920fba82f in ?? ??:0 #166 0x432548 in _start ??:? #167 0x432548 in ?? ??:0 0x60200000e72f is located 1 bytes to the left of 2-byte region [0x60200000e730,0x60200000e732) allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x7f191d1f5964 in my_strdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:169 (discriminator 2) #3 0x7f191d1f5964 in ?? ??:0 #2 0x7ffd5c1c7aff () SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x2754a) Shadow bytes around the buggy address: 0x0c047fff9c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fff9ce0: fa fa fa fa fa[fa]02 fa fa fa fd fa fa fa fd fa 0x0c047fff9cf0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d10: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d20: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d30: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==17908==ABORTING ---------- components: Interpreter Core files: ctypes_4992 messages: 287326 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: heap-buffer-overflow on address 0x60200000e72f type: security versions: Python 3.6 Added file: http://bugs.python.org/file46585/ctypes_4992 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:48:13 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:48:13 +0000 Subject: [New-bugs-announce] [issue29491] AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 Message-ID: <1486565293.5.0.613764150228.issue29491@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Inferior 1 (process 19397) exited with code 01] ASAN: ================================================================= ==17935==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 at pc 0x7f6e87941564 bp 0x7fff533392c0 sp 0x7fff533392b8 READ of size 4 at 0x60200000e734 thread T0 #0 0x7f6e87941563 in Pointer_subscript /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:5013 #1 0x7f6e87941563 in ?? ??:0 #2 0x79987c in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:1458 (discriminator 1) #3 0x79987c in ?? ??:0 #4 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #5 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #6 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #7 0x7ab4cb in ?? ??:0 #8 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #9 0x7a76f2 in ?? ??:0 #10 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #11 0x7995cc in ?? ??:0 #12 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #13 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #14 0x7a9847 in ?? ??:0 #15 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #16 0x7ac2ea in ?? ??:0 #17 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #18 0x574668 in ?? ??:0 #19 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #20 0x5749fa in ?? ??:0 #21 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #22 0x573e9b in ?? ??:0 #23 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #24 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #25 0x793369 in ?? ??:0 #26 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #27 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #28 0x7a9847 in ?? ??:0 #29 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #30 0x7ac2ea in ?? ??:0 #31 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #32 0x574668 in ?? ??:0 #33 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #34 0x5749fa in ?? ??:0 #35 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #36 0x573e9b in ?? ??:0 #37 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #38 0x66efe4 in ?? ??:0 #39 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #40 0x5745f0 in ?? ??:0 #41 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #42 0x7a7429 in ?? ??:0 #43 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #44 0x7995cc in ?? ??:0 #45 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #46 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #47 0x7a9847 in ?? ??:0 #48 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #49 0x7ac2ea in ?? ??:0 #50 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #51 0x574668 in ?? ??:0 #52 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #53 0x5749fa in ?? ??:0 #54 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #55 0x573e9b in ?? ??:0 #56 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #57 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #58 0x793369 in ?? ??:0 #59 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #60 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #61 0x7a9847 in ?? ??:0 #62 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #63 0x7ac2ea in ?? ??:0 #64 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #65 0x574668 in ?? ??:0 #66 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #67 0x5749fa in ?? ??:0 #68 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #69 0x573e9b in ?? ??:0 #70 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #71 0x66efe4 in ?? ??:0 #72 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #73 0x5745f0 in ?? ??:0 #74 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #75 0x7a7429 in ?? ??:0 #76 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #77 0x7995cc in ?? ??:0 #78 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #79 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #80 0x7a9847 in ?? ??:0 #81 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #82 0x7ac2ea in ?? ??:0 #83 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #84 0x574668 in ?? ??:0 #85 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #86 0x5749fa in ?? ??:0 #87 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #88 0x573e9b in ?? ??:0 #89 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #90 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #91 0x793369 in ?? ??:0 #92 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #93 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #94 0x7a9847 in ?? ??:0 #95 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #96 0x7ac2ea in ?? ??:0 #97 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #98 0x574668 in ?? ??:0 #99 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #100 0x5749fa in ?? ??:0 #101 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #102 0x573e9b in ?? ??:0 #103 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #104 0x66efe4 in ?? ??:0 #105 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #106 0x5745f0 in ?? ??:0 #107 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #108 0x7a7429 in ?? ??:0 #109 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #110 0x7995cc in ?? ??:0 #111 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #112 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #113 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #114 0x7ab4cb in ?? ??:0 #115 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #116 0x7a76f2 in ?? ??:0 #117 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #118 0x7995cc in ?? ??:0 #119 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #120 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #121 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #122 0x7ab4cb in ?? ??:0 #123 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #124 0x7a76f2 in ?? ??:0 #125 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #126 0x7995cc in ?? ??:0 #127 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #128 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #129 0x7a9847 in ?? ??:0 #130 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #131 0x7ac2ea in ?? ??:0 #132 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #133 0x574668 in ?? ??:0 #134 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #135 0x5749fa in ?? ??:0 #136 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #137 0x573e9b in ?? ??:0 #138 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #139 0x6713f8 in ?? ??:0 #140 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #141 0x666d8d in ?? ??:0 #142 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #143 0x5745f0 in ?? ??:0 #144 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #145 0x7a7429 in ?? ??:0 #146 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #147 0x7995cc in ?? ??:0 #148 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #149 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #150 0x7a9847 in ?? ??:0 #151 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #152 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #153 0x78e0df in ?? ??:0 #154 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #155 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #156 0x5142f5 in ?? ??:0 #157 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #158 0x512afa in ?? ??:0 #159 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #160 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #161 0x53eefd in ?? ??:0 #162 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #163 0x503d16 in ?? ??:0 #164 0x7f6e8b28d82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #165 0x7f6e8b28d82f in ?? ??:0 #166 0x432548 in _start ??:? #167 0x432548 in ?? ??:0 0x60200000e734 is located 0 bytes to the right of 4-byte region [0x60200000e730,0x60200000e734) allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x7f6e874cc9bc in my_wcsdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:185 (discriminator 1) #3 0x7f6e874cc9bc in ?? ??:0 #2 0x7fff53338f5f () SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/test/check/PythonASAN/build/lib.linux-x86_64-3.6/_ctypes.cpython-36m-x86_64-linux-gnu.so+0x27563) Shadow bytes around the buggy address: 0x0c047fff9c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fff9ce0: fa fa fa fa fa fa[04]fa fa fa fd fa fa fa fd fa 0x0c047fff9cf0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d10: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d20: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fff9d30: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==17935==ABORTING ---------- components: Interpreter Core files: ctypes_5013 messages: 287327 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: heap-buffer-overflow on address 0x60200000e734 versions: Python 3.6 Added file: http://bugs.python.org/file46586/ctypes_5013 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:49:50 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:49:50 +0000 Subject: [New-bugs-announce] [issue29492] AddressSanitizer: SEGV on unknown address 0x0000a0013639 Message-ID: <1486565390.59.0.464737357011.issue29492@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x000000000049b304 in dict_dealloc (mp=0x7ffff5b44510) at Objects/dictobject.c:1925 1925 Py_XDECREF(values[i]); Description: Access violation during branch instruction Short description: BranchAv (4/22) Hash: 88d6a4b120e0fabdcb9b56178f8ef166.2c4f31b17f90f974f2ff23d3286fcbbd Exploitability Classification: EXPLOITABLE Explanation: The target crashed on a branch instruction, which may indicate that the control flow is tainted. Other tags: DestAv (8/22), AccessViolation (21/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18235==ERROR: AddressSanitizer: SEGV on unknown address 0x0000a0013639 (pc 0x00000061637c bp 0x7efd09781be8 sp 0x7ffe3da51c50 T0) #0 0x61637b in dict_dealloc /home/test/check/PythonASAN/Objects/dictobject.c:1925 (discriminator 5) #1 0x61637b in ?? ??:0 #2 0x65d3b9 in subtype_dealloc /home/test/check/PythonASAN/Objects/typeobject.c:1207 (discriminator 3) #3 0x65d3b9 in ?? ??:0 #4 0x5d10da in frame_dealloc /home/test/check/PythonASAN/Objects/frameobject.c:423 (discriminator 5) #5 0x5d10da in ?? ??:0 #6 0x7a98ca in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4130 (discriminator 3) #7 0x7a98ca in ?? ??:0 #8 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #9 0x7ab648 in ?? ??:0 #10 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #11 0x7a76f2 in ?? ??:0 #12 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #13 0x7995cc in ?? ??:0 #14 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #15 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #16 0x7a9847 in ?? ??:0 #17 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #18 0x7ac2ea in ?? ??:0 #19 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #20 0x574668 in ?? ??:0 #21 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #22 0x5749fa in ?? ??:0 #23 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #24 0x573e9b in ?? ??:0 #25 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #26 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #27 0x793369 in ?? ??:0 #28 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #29 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #30 0x7a9847 in ?? ??:0 #31 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #32 0x7ac2ea in ?? ??:0 #33 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #34 0x574668 in ?? ??:0 #35 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #36 0x5749fa in ?? ??:0 #37 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #38 0x573e9b in ?? ??:0 #39 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #40 0x66efe4 in ?? ??:0 #41 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #42 0x5745f0 in ?? ??:0 #43 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #44 0x7a7429 in ?? ??:0 #45 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #46 0x7995cc in ?? ??:0 #47 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #48 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #49 0x7a9847 in ?? ??:0 #50 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #51 0x7ac2ea in ?? ??:0 #52 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #53 0x574668 in ?? ??:0 #54 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #55 0x5749fa in ?? ??:0 #56 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #57 0x573e9b in ?? ??:0 #58 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #59 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #60 0x793369 in ?? ??:0 #61 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #62 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #63 0x7a9847 in ?? ??:0 #64 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #65 0x7ac2ea in ?? ??:0 #66 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #67 0x574668 in ?? ??:0 #68 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #69 0x5749fa in ?? ??:0 #70 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #71 0x573e9b in ?? ??:0 #72 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #73 0x66efe4 in ?? ??:0 #74 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #75 0x5745f0 in ?? ??:0 #76 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #77 0x7a7429 in ?? ??:0 #78 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #79 0x7995cc in ?? ??:0 #80 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #81 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #82 0x7a9847 in ?? ??:0 #83 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #84 0x7ac2ea in ?? ??:0 #85 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #86 0x574668 in ?? ??:0 #87 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #88 0x5749fa in ?? ??:0 #89 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #90 0x573e9b in ?? ??:0 #91 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #92 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #93 0x793369 in ?? ??:0 #94 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #95 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #96 0x7a9847 in ?? ??:0 #97 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #98 0x7ac2ea in ?? ??:0 #99 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #100 0x574668 in ?? ??:0 #101 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #102 0x5749fa in ?? ??:0 #103 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #104 0x573e9b in ?? ??:0 #105 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #106 0x66efe4 in ?? ??:0 #107 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #108 0x5745f0 in ?? ??:0 #109 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #110 0x7a7429 in ?? ??:0 #111 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #112 0x7995cc in ?? ??:0 #113 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #114 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #115 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #116 0x7ab4cb in ?? ??:0 #117 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #118 0x7a76f2 in ?? ??:0 #119 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #120 0x7995cc in ?? ??:0 #121 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #122 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #123 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #124 0x7ab4cb in ?? ??:0 #125 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #126 0x7a76f2 in ?? ??:0 #127 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #128 0x7995cc in ?? ??:0 #129 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #130 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #131 0x7a9847 in ?? ??:0 #132 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #133 0x7ac2ea in ?? ??:0 #134 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #135 0x574668 in ?? ??:0 #136 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #137 0x5749fa in ?? ??:0 #138 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #139 0x573e9b in ?? ??:0 #140 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #141 0x6713f8 in ?? ??:0 #142 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #143 0x666d8d in ?? ??:0 #144 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #145 0x5745f0 in ?? ??:0 #146 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #147 0x7a7429 in ?? ??:0 #148 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #149 0x7995cc in ?? ??:0 #150 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #151 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #152 0x7a9847 in ?? ??:0 #153 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #154 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #155 0x78e0df in ?? ??:0 #156 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #157 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #158 0x5142f5 in ?? ??:0 #159 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #160 0x512afa in ?? ??:0 #161 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #162 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #163 0x53eefd in ?? ??:0 #164 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #165 0x503d16 in ?? ??:0 #166 0x7efd0d28782f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #167 0x7efd0d28782f in ?? ??:0 #168 0x432548 in _start ??:? #169 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x61637b) ==18235==ABORTING ---------- components: Interpreter Core files: dicobj_1925 messages: 287329 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x0000a0013639 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46587/dicobj_1925 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:50:45 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:50:45 +0000 Subject: [New-bugs-announce] [issue29493] AddressSanitizer: SEGV on unknown address 0x000cffff800d Message-ID: <1486565445.54.0.388710643733.issue29493@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x000000000043d563 in PyObject_GC_UnTrack (op=0x7ffff3810400) at Modules/gcmodule.c:1699 1699 _PyObject_GC_UNTRACK(op); Description: Access violation on destination operand Short description: DestAv (8/22) Hash: a30125899c34aa234161214a7afc7066.d78488ccad0508b81b411140385e7113 Exploitability Classification: EXPLOITABLE Explanation: The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control the write address and/or value. Other tags: AccessViolation (21/22) ASAN: EsFASAN:DEADLYSIGNAL ================================================================= ==18094==ERROR: AddressSanitizer: SEGV on unknown address 0x000cffff800d (pc 0x000000543039 bp 0x0fec572c0c81 sp 0x7ffc421b9cf0 T0) #0 0x543038 in PyObject_GC_UnTrack /home/test/check/PythonASAN/Modules/gcmodule.c:1699 (discriminator 4) #1 0x543038 in ?? ??:0 #2 0x65ca2f in subtype_dealloc /home/test/check/PythonASAN/Objects/typeobject.c:1133 #3 0x65ca2f in ?? ??:0 #4 0x5d10da in frame_dealloc /home/test/check/PythonASAN/Objects/frameobject.c:423 (discriminator 5) #5 0x5d10da in ?? ??:0 #6 0x5304c4 in tb_dealloc /home/test/check/PythonASAN/Python/traceback.c:55 (discriminator 5) #7 0x5304c4 in ?? ??:0 #8 0x530456 in tb_dealloc /home/test/check/PythonASAN/Python/traceback.c:54 (discriminator 5) #9 0x530456 in ?? ??:0 #10 0x530456 in tb_dealloc /home/test/check/PythonASAN/Python/traceback.c:54 (discriminator 5) #11 0x530456 in ?? ??:0 #12 0x5b3b49 in BaseException_clear /home/test/check/PythonASAN/Objects/exceptions.c:76 (discriminator 5) #13 0x5b3b49 in ?? ??:0 #14 0x5b3742 in BaseException_dealloc /home/test/check/PythonASAN/Objects/exceptions.c:86 #15 0x5b3742 in ?? ??:0 #16 0x656df9 in tupledealloc /home/test/check/PythonASAN/Objects/tupleobject.c:243 (discriminator 5) #17 0x656df9 in ?? ??:0 #18 0x656df9 in tupledealloc /home/test/check/PythonASAN/Objects/tupleobject.c:243 (discriminator 5) #19 0x656df9 in ?? ??:0 #20 0x5e5c19 in list_clear /home/test/check/PythonASAN/Objects/listobject.c:562 (discriminator 5) #21 0x5e5c19 in listclear /home/test/check/PythonASAN/Objects/listobject.c:763 (discriminator 5) #22 0x5e5c19 in ?? ??:0 #23 0x632208 in _PyCFunction_FastCallDict /home/test/check/PythonASAN/Objects/methodobject.c:192 #24 0x632208 in ?? ??:0 #25 0x7a7751 in call_function /home/test/check/PythonASAN/Python/ceval.c:4788 (discriminator 17) #26 0x7a7751 in ?? ??:0 #27 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #28 0x7995cc in ?? ??:0 #29 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #30 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #31 0x7a9847 in ?? ??:0 #32 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #33 0x7ac2ea in ?? ??:0 #34 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #35 0x574668 in ?? ??:0 #36 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #37 0x5749fa in ?? ??:0 #38 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #39 0x573e9b in ?? ??:0 #40 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #41 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #42 0x793369 in ?? ??:0 #43 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #44 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #45 0x7a9847 in ?? ??:0 #46 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #47 0x7ac2ea in ?? ??:0 #48 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #49 0x574668 in ?? ??:0 #50 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #51 0x5749fa in ?? ??:0 #52 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #53 0x573e9b in ?? ??:0 #54 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #55 0x66efe4 in ?? ??:0 #56 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #57 0x5745f0 in ?? ??:0 #58 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #59 0x7a7429 in ?? ??:0 #60 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #61 0x7995cc in ?? ??:0 #62 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #63 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #64 0x7a9847 in ?? ??:0 #65 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #66 0x7ac2ea in ?? ??:0 #67 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #68 0x574668 in ?? ??:0 #69 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #70 0x5749fa in ?? ??:0 #71 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #72 0x573e9b in ?? ??:0 #73 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #74 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #75 0x793369 in ?? ??:0 #76 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #77 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #78 0x7a9847 in ?? ??:0 #79 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #80 0x7ac2ea in ?? ??:0 #81 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #82 0x574668 in ?? ??:0 #83 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #84 0x5749fa in ?? ??:0 #85 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #86 0x573e9b in ?? ??:0 #87 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #88 0x66efe4 in ?? ??:0 #89 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #90 0x5745f0 in ?? ??:0 #91 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #92 0x7a7429 in ?? ??:0 #93 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #94 0x7995cc in ?? ??:0 #95 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #96 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #97 0x7a9847 in ?? ??:0 #98 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #99 0x7ac2ea in ?? ??:0 #100 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #101 0x574668 in ?? ??:0 #102 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #103 0x5749fa in ?? ??:0 #104 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #105 0x573e9b in ?? ??:0 #106 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #107 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #108 0x793369 in ?? ??:0 #109 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #110 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #111 0x7a9847 in ?? ??:0 #112 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #113 0x7ac2ea in ?? ??:0 #114 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #115 0x574668 in ?? ??:0 #116 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #117 0x5749fa in ?? ??:0 #118 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #119 0x573e9b in ?? ??:0 #120 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #121 0x66efe4 in ?? ??:0 #122 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #123 0x5745f0 in ?? ??:0 #124 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #125 0x7a7429 in ?? ??:0 #126 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #127 0x7995cc in ?? ??:0 #128 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #129 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #130 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #131 0x7ab4cb in ?? ??:0 #132 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #133 0x7a76f2 in ?? ??:0 #134 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #135 0x7995cc in ?? ??:0 #136 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #137 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #138 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #139 0x7ab4cb in ?? ??:0 #140 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #141 0x7a76f2 in ?? ??:0 #142 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #143 0x7995cc in ?? ??:0 #144 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #145 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #146 0x7a9847 in ?? ??:0 #147 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #148 0x7ac2ea in ?? ??:0 #149 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #150 0x574668 in ?? ??:0 #151 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #152 0x5749fa in ?? ??:0 #153 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #154 0x573e9b in ?? ??:0 #155 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #156 0x6713f8 in ?? ??:0 #157 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #158 0x666d8d in ?? ??:0 #159 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #160 0x5745f0 in ?? ??:0 #161 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #162 0x7a7429 in ?? ??:0 #163 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #164 0x7995cc in ?? ??:0 #165 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #166 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #167 0x7a9847 in ?? ??:0 #168 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #169 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #170 0x78e0df in ?? ??:0 #171 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #172 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #173 0x5142f5 in ?? ??:0 #174 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #175 0x512afa in ?? ??:0 #176 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #177 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #178 0x53eefd in ?? ??:0 #179 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #180 0x503d16 in ?? ??:0 #181 0x7f62bf5d482f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #182 0x7f62bf5d482f in ?? ??:0 #183 0x432548 in _start ??:? #184 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x543038) ==18094==ABORTING ---------- components: Interpreter Core files: gcmodule_1699 messages: 287330 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x000cffff800d type: security versions: Python 3.6 Added file: http://bugs.python.org/file46588/gcmodule_1699 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:51:44 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:51:44 +0000 Subject: [New-bugs-announce] [issue29494] AddressSanitizer: SEGV on unknown address 0x00009fff8001 Message-ID: <1486565504.05.0.501881320896.issue29494@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. visit_decref (op=0x100000000, data=0x0) at Modules/gcmodule.c:374 374 if (PyObject_IS_GC(op)) { Description: Access violation on source operand Short description: SourceAv (19/22) Hash: 5ae0cf182ca6c91339ba4d86e35281e3.974794321b75f348830f6ff316f662f4 Exploitability Classification: UNKNOWN Explanation: The target crashed on an access violation at an address matching the source operand of the current instruction. This likely indicates a read access violation. Other tags: AccessViolation (21/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18468==ERROR: AddressSanitizer: SEGV on unknown address 0x00009fff8001 (pc 0x000000544b5f bp 0x7ffeeb051e90 sp 0x7ffeeb051c30 T0) #0 0x544b5e in visit_decref /home/test/check/PythonASAN/Modules/gcmodule.c:374 #1 0x544b5e in ?? ??:0 #2 0x5d7035 in func_traverse /home/test/check/PythonASAN/Objects/funcobject.c:558 (discriminator 8) #3 0x5d7035 in ?? ??:0 #4 0x540ca1 in subtract_refs /home/test/check/PythonASAN/Modules/gcmodule.c:399 #5 0x540ca1 in collect /home/test/check/PythonASAN/Modules/gcmodule.c:956 #6 0x540ca1 in ?? ??:0 #7 0x5406ed in collect_with_callback /home/test/check/PythonASAN/Modules/gcmodule.c:1128 #8 0x5406ed in PyGC_Collect /home/test/check/PythonASAN/Modules/gcmodule.c:1592 #9 0x5406ed in _PyGC_CollectIfEnabled /home/test/check/PythonASAN/Modules/gcmodule.c:1605 #10 0x5406ed in ?? ??:0 #11 0x50d31a in Py_FinalizeEx /home/test/check/PythonASAN/Python/pylifecycle.c:603 #12 0x50d31a in ?? ??:0 #13 0x50e127 in Py_Exit /home/test/check/PythonASAN/Python/pylifecycle.c:1537 #14 0x50e127 in ?? ??:0 #15 0x51537b in handle_system_exit /home/test/check/PythonASAN/Python/pythonrun.c:602 #16 0x51537b in ?? ??:0 #17 0x5146b0 in PyErr_PrintEx /home/test/check/PythonASAN/Python/pythonrun.c:612 #18 0x5146b0 in ?? ??:0 #19 0x512c87 in PyErr_Print /home/test/check/PythonASAN/Python/pythonrun.c:508 #20 0x512c87 in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:401 #21 0x512c87 in ?? ??:0 #22 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #23 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #24 0x53eefd in ?? ??:0 #25 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #26 0x503d16 in ?? ??:0 #27 0x7fcae111d82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #28 0x7fcae111d82f in ?? ??:0 #29 0x432548 in _start ??:? #30 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x544b5e) ==18468==ABORTING ---------- components: Interpreter Core files: gcmodule_374 messages: 287331 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x00009fff8001 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46589/gcmodule_374 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:53:07 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:53:07 +0000 Subject: [New-bugs-announce] [issue29495] AddressSanitizer: SEGV on unknown address 0x02007ea947c3 Message-ID: <1486565587.91.0.875598249655.issue29495@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. strlen () at ../sysdeps/x86_64/strlen.S:106 Description: Access violation near NULL on source operand Short description: SourceAvNearNull (16/22) Hash: 524fc888253e60855a72647740103ec8.0dd959fe8965dda124a3c8d6b55807e3 Exploitability Classification: PROBABLY_NOT_EXPLOITABLE Explanation: The target crashed on an access violation at an address matching the source operand of the current instruction. This likely indicates a read access violation, which may mean the application crashed on a simple NULL dereference to data structure that has no immediate effect on control of the processor. Other tags: AccessViolation (21/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18706==ERROR: AddressSanitizer: SEGV on unknown address 0x02007ea947c3 (pc 0x00000044ffe7 bp 0x7fffaa71f040 sp 0x7fffaa71e7e0 T0) #0 0x44ffe6 in __interceptor_strlen.part.45 asan_interceptors.cc.o:? #1 0x44ffe6 in ?? ??:0 #2 0x7f2309ccc95b in my_strdup /home/test/check/PythonASAN/Modules/_ctypes/_ctypes_test.c:169 (discriminator 1) #3 0x7f2309ccc95b in ?? ??:0 #4 0x7f2309f17e3f in ffi_call_unix64 ??:? #5 0x7f2309f17e3f in ?? ??:0 #6 0x7f2309f178aa in ffi_call ??:? #7 0x7f2309f178aa in ?? ??:0 #8 0x7f230a145311 in _call_function_pointer /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:809 #9 0x7f230a145311 in _ctypes_callproc /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:1147 #10 0x7f230a145311 in ?? ??:0 #11 0x7f230a134199 in PyCFuncPtr_call /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:3870 #12 0x7f230a134199 in ?? ??:0 #13 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #14 0x5745f0 in ?? ??:0 #15 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #16 0x7a7429 in ?? ??:0 #17 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #18 0x7995cc in ?? ??:0 #19 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #20 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #21 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #22 0x7ab4cb in ?? ??:0 #23 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #24 0x7a76f2 in ?? ??:0 #25 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #26 0x7995cc in ?? ??:0 #27 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #28 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #29 0x7a9847 in ?? ??:0 #30 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #31 0x7ac2ea in ?? ??:0 #32 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #33 0x574668 in ?? ??:0 #34 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #35 0x5749fa in ?? ??:0 #36 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #37 0x573e9b in ?? ??:0 #38 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #39 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #40 0x793369 in ?? ??:0 #41 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #42 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #43 0x7a9847 in ?? ??:0 #44 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #45 0x7ac2ea in ?? ??:0 #46 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #47 0x574668 in ?? ??:0 #48 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #49 0x5749fa in ?? ??:0 #50 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #51 0x573e9b in ?? ??:0 #52 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #53 0x66efe4 in ?? ??:0 #54 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #55 0x5745f0 in ?? ??:0 #56 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #57 0x7a7429 in ?? ??:0 #58 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #59 0x7995cc in ?? ??:0 #60 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #61 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #62 0x7a9847 in ?? ??:0 #63 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #64 0x7ac2ea in ?? ??:0 #65 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #66 0x574668 in ?? ??:0 #67 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #68 0x5749fa in ?? ??:0 #69 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #70 0x573e9b in ?? ??:0 #71 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #72 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #73 0x793369 in ?? ??:0 #74 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #75 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #76 0x7a9847 in ?? ??:0 #77 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #78 0x7ac2ea in ?? ??:0 #79 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #80 0x574668 in ?? ??:0 #81 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #82 0x5749fa in ?? ??:0 #83 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #84 0x573e9b in ?? ??:0 #85 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #86 0x66efe4 in ?? ??:0 #87 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #88 0x5745f0 in ?? ??:0 #89 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #90 0x7a7429 in ?? ??:0 #91 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #92 0x7995cc in ?? ??:0 #93 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #94 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #95 0x7a9847 in ?? ??:0 #96 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #97 0x7ac2ea in ?? ??:0 #98 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #99 0x574668 in ?? ??:0 #100 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #101 0x5749fa in ?? ??:0 #102 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #103 0x573e9b in ?? ??:0 #104 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #105 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #106 0x793369 in ?? ??:0 #107 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #108 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #109 0x7a9847 in ?? ??:0 #110 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #111 0x7ac2ea in ?? ??:0 #112 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #113 0x574668 in ?? ??:0 #114 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #115 0x5749fa in ?? ??:0 #116 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #117 0x573e9b in ?? ??:0 #118 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #119 0x66efe4 in ?? ??:0 #120 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #121 0x5745f0 in ?? ??:0 #122 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #123 0x7a7429 in ?? ??:0 #124 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #125 0x7995cc in ?? ??:0 #126 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #127 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #128 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #129 0x7ab4cb in ?? ??:0 #130 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #131 0x7a76f2 in ?? ??:0 #132 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #133 0x7995cc in ?? ??:0 #134 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #135 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #136 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #137 0x7ab4cb in ?? ??:0 #138 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #139 0x7a76f2 in ?? ??:0 #140 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #141 0x7995cc in ?? ??:0 #142 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #143 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #144 0x7a9847 in ?? ??:0 #145 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #146 0x7ac2ea in ?? ??:0 #147 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #148 0x574668 in ?? ??:0 #149 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #150 0x5749fa in ?? ??:0 #151 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #152 0x573e9b in ?? ??:0 #153 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #154 0x6713f8 in ?? ??:0 #155 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #156 0x666d8d in ?? ??:0 #157 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #158 0x5745f0 in ?? ??:0 #159 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #160 0x7a7429 in ?? ??:0 #161 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #162 0x7995cc in ?? ??:0 #163 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #164 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #165 0x7a9847 in ?? ??:0 #166 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #167 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #168 0x78e0df in ?? ??:0 #169 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #170 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #171 0x5142f5 in ?? ??:0 #172 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #173 0x512afa in ?? ??:0 #174 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #175 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #176 0x53eefd in ?? ??:0 #177 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #178 0x503d16 in ?? ??:0 #179 0x7f230da9b82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #180 0x7f230da9b82f in ?? ??:0 #181 0x432548 in _start ??:? #182 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x44ffe6) ==18706==ABORTING ---------- components: Interpreter Core files: inter messages: 287334 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x02007ea947c3 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46590/inter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:53:50 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:53:50 +0000 Subject: [New-bugs-announce] [issue29496] AddressSanitizer: SEGV on unknown address 0x01ffe96de071 Message-ID: <1486565630.26.0.23581787911.issue29496@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Inferior 1 (process 19429) exited with code 01] ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18136==ERROR: AddressSanitizer: SEGV on unknown address 0x01ffe96de071 (pc 0x0000005e9305 bp 0x7ffc234b3300 sp 0x7ffc234b3240 T0) #0 0x5e9304 in PyLong_AsLongAndOverflow /home/test/check/PythonASAN/Objects/longobject.c:408 #1 0x5e9304 in ?? ??:0 #2 0x5e9658 in PyLong_AsLong /home/test/check/PythonASAN/Objects/longobject.c:474 (discriminator 1) #3 0x5e9658 in ?? ??:0 #4 0x7fda5a8bfe3f in ffi_call_unix64 ??:? #5 0x7fda5a8bfe3f in ?? ??:0 #6 0x7fda5a8bf8aa in ffi_call ??:? #7 0x7fda5a8bf8aa in ?? ??:0 #8 0x7fda5aaed311 in _call_function_pointer /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:809 #9 0x7fda5aaed311 in _ctypes_callproc /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:1147 #10 0x7fda5aaed311 in ?? ??:0 #11 0x7fda5aadc199 in PyCFuncPtr_call /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:3870 #12 0x7fda5aadc199 in ?? ??:0 #13 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #14 0x5745f0 in ?? ??:0 #15 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #16 0x7a7429 in ?? ??:0 #17 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #18 0x7995cc in ?? ??:0 #19 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #20 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #21 0x7a9847 in ?? ??:0 #22 0x78e15d in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #23 0x78e15d in ?? ??:0 #24 0x784f1a in builtin___build_class__ /home/test/check/PythonASAN/Python/bltinmodule.c:170 #25 0x784f1a in ?? ??:0 #26 0x631f93 in _PyCFunction_FastCallDict /home/test/check/PythonASAN/Objects/methodobject.c:231 #27 0x631f93 in ?? ??:0 #28 0x7a7751 in call_function /home/test/check/PythonASAN/Python/ceval.c:4788 (discriminator 17) #29 0x7a7751 in ?? ??:0 #30 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #31 0x7995cc in ?? ??:0 #32 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #33 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #34 0x7a9847 in ?? ??:0 #35 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #36 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #37 0x78e0df in ?? ??:0 #38 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #39 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #40 0x5142f5 in ?? ??:0 #41 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #42 0x512afa in ?? ??:0 #43 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #44 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #45 0x53eefd in ?? ??:0 #46 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #47 0x503d16 in ?? ??:0 #48 0x7fda5deaf82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #49 0x7fda5deaf82f in ?? ??:0 #50 0x432548 in _start ??:? #51 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x5e9304) ==18136==ABORTING ---------- components: Interpreter Core files: longobj_408 messages: 287335 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x01ffe96de071 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46591/longobj_408 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:54:39 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:54:39 +0000 Subject: [New-bugs-announce] [issue29497] AddressSanitizer: SEGV on unknown address 0x000000000008 Message-ID: <1486565679.01.0.635065355996.issue29497@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGABRT, Aborted. 0x00007ffff7116418 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 Description: Heap error Short description: HeapError (10/22) Hash: 2aa3ac417e1aa62c7fe1524ebca9f7a3.8d7f0ad1f2db61942ed3977c83757030 Exploitability Classification: EXPLOITABLE Explanation: The target's backtrace indicates that libc has detected a heap error or that the target was executing a heap function when it stopped. This could be due to heap corruption, passing a bad pointer to a heap function such as free(), etc. Since heap errors might include buffer overflows, use-after-free situations, etc. they are generally considered exploitable. Other tags: AbortSignal (20/22) ASAN: ASAN:DEADLYSIGNAL ================================================================= ==18277==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7f65f421d380 bp 0x7f65f4560b20 sp 0x7ffe10375320 T0) #0 0x7f65f421d37f in _int_free /build/glibc-GKVZIf/glibc-2.23/malloc/malloc.c:4057 #1 0x7f65f421d37f in ?? ??:0 #2 0x7f65f4220abb in __GI___libc_free /build/glibc-GKVZIf/glibc-2.23/malloc/malloc.c:2969 (discriminator 4) #3 0x7f65f4220abb in ?? ??:0 #4 0x7f65f0640e3f in ffi_call_unix64 ??:? #5 0x7f65f0640e3f in ?? ??:0 #6 0x7f65f06408aa in ffi_call ??:? #7 0x7f65f06408aa in ?? ??:0 #8 0x7f65f0885311 in _call_function_pointer /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:809 #9 0x7f65f0885311 in _ctypes_callproc /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:1147 #10 0x7f65f0885311 in ?? ??:0 #11 0x7f65f0874199 in PyCFuncPtr_call /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:3870 #12 0x7f65f0874199 in ?? ??:0 #13 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #14 0x5745f0 in ?? ??:0 #15 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #16 0x7a7429 in ?? ??:0 #17 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #18 0x7995cc in ?? ??:0 #19 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #20 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #21 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #22 0x7ab4cb in ?? ??:0 #23 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #24 0x7a76f2 in ?? ??:0 #25 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #26 0x7995cc in ?? ??:0 #27 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #28 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #29 0x7a9847 in ?? ??:0 #30 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #31 0x7ac2ea in ?? ??:0 #32 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #33 0x574668 in ?? ??:0 #34 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #35 0x5749fa in ?? ??:0 #36 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #37 0x573e9b in ?? ??:0 #38 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #39 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #40 0x793369 in ?? ??:0 #41 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #42 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #43 0x7a9847 in ?? ??:0 #44 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #45 0x7ac2ea in ?? ??:0 #46 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #47 0x574668 in ?? ??:0 #48 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #49 0x5749fa in ?? ??:0 #50 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #51 0x573e9b in ?? ??:0 #52 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #53 0x66efe4 in ?? ??:0 #54 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #55 0x5745f0 in ?? ??:0 #56 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #57 0x7a7429 in ?? ??:0 #58 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #59 0x7995cc in ?? ??:0 #60 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #61 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #62 0x7a9847 in ?? ??:0 #63 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #64 0x7ac2ea in ?? ??:0 #65 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #66 0x574668 in ?? ??:0 #67 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #68 0x5749fa in ?? ??:0 #69 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #70 0x573e9b in ?? ??:0 #71 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #72 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #73 0x793369 in ?? ??:0 #74 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #75 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #76 0x7a9847 in ?? ??:0 #77 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #78 0x7ac2ea in ?? ??:0 #79 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #80 0x574668 in ?? ??:0 #81 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #82 0x5749fa in ?? ??:0 #83 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #84 0x573e9b in ?? ??:0 #85 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #86 0x66efe4 in ?? ??:0 #87 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #88 0x5745f0 in ?? ??:0 #89 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #90 0x7a7429 in ?? ??:0 #91 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #92 0x7995cc in ?? ??:0 #93 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #94 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #95 0x7a9847 in ?? ??:0 #96 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #97 0x7ac2ea in ?? ??:0 #98 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #99 0x574668 in ?? ??:0 #100 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #101 0x5749fa in ?? ??:0 #102 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #103 0x573e9b in ?? ??:0 #104 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #105 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #106 0x793369 in ?? ??:0 #107 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #108 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #109 0x7a9847 in ?? ??:0 #110 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #111 0x7ac2ea in ?? ??:0 #112 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #113 0x574668 in ?? ??:0 #114 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #115 0x5749fa in ?? ??:0 #116 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #117 0x573e9b in ?? ??:0 #118 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #119 0x66efe4 in ?? ??:0 #120 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #121 0x5745f0 in ?? ??:0 #122 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #123 0x7a7429 in ?? ??:0 #124 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #125 0x7995cc in ?? ??:0 #126 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #127 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #128 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #129 0x7ab4cb in ?? ??:0 #130 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #131 0x7a76f2 in ?? ??:0 #132 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #133 0x7995cc in ?? ??:0 #134 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #135 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #136 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #137 0x7ab4cb in ?? ??:0 #138 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #139 0x7a76f2 in ?? ??:0 #140 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #141 0x7995cc in ?? ??:0 #142 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #143 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #144 0x7a9847 in ?? ??:0 #145 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #146 0x7ac2ea in ?? ??:0 #147 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #148 0x574668 in ?? ??:0 #149 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #150 0x5749fa in ?? ??:0 #151 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #152 0x573e9b in ?? ??:0 #153 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #154 0x6713f8 in ?? ??:0 #155 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #156 0x666d8d in ?? ??:0 #157 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #158 0x5745f0 in ?? ??:0 #159 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #160 0x7a7429 in ?? ??:0 #161 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #162 0x7995cc in ?? ??:0 #163 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #164 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #165 0x7a9847 in ?? ??:0 #166 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #167 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #168 0x78e0df in ?? ??:0 #169 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #170 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #171 0x5142f5 in ?? ??:0 #172 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #173 0x512afa in ?? ??:0 #174 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #175 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #176 0x53eefd in ?? ??:0 #177 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #178 0x503d16 in ?? ??:0 #179 0x7f65f41bd82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #180 0x7f65f41bd82f in ?? ??:0 #181 0x432548 in _start ??:? #182 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x8037f) ==18277==ABORTING ---------- components: Interpreter Core files: malloc_4057 messages: 287336 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x000000000008 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46592/malloc_4057 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:55:22 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:55:22 +0000 Subject: [New-bugs-announce] [issue29498] AddressSanitizer: SEGV on unknown address 0x0005ffff800d Message-ID: <1486565722.07.0.443557463109.issue29498@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. _PyObject_GenericGetAttrWithDict (dict=0x2c0000006f, name=0x7ffff7eed3b0, obj=0x7ffff628ebf8) at Objects/object.c:1088 1088 Py_INCREF(dict); Description: Access violation on destination operand Short description: DestAv (8/22) Hash: 5fba3f64e0a5cd874121e05187de0b92.c7630c31a2ff26cdc6fb85881fa40252 Exploitability Classification: EXPLOITABLE Explanation: The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control the write address and/or value. Other tags: AccessViolation (21/22) ASAN: EsEASAN:DEADLYSIGNAL ================================================================= ==18600==ERROR: AddressSanitizer: SEGV on unknown address 0x0005ffff800d (pc 0x00000063acfe bp 0x7f86cde063b0 sp 0x7fffa5d9ea90 T0) #0 0x63acfd in _PyObject_GenericGetAttrWithDict /home/test/check/PythonASAN/Objects/object.c:1088 #1 0x63acfd in ?? ??:0 #2 0x7966cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:2815 (discriminator 1) #3 0x7966cc in ?? ??:0 #4 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #5 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #6 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #7 0x7ab4cb in ?? ??:0 #8 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #9 0x7a76f2 in ?? ??:0 #10 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #11 0x7995cc in ?? ??:0 #12 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #13 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #14 0x7a9847 in ?? ??:0 #15 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #16 0x7ac2ea in ?? ??:0 #17 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #18 0x574668 in ?? ??:0 #19 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #20 0x5749fa in ?? ??:0 #21 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #22 0x573e9b in ?? ??:0 #23 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #24 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #25 0x793369 in ?? ??:0 #26 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #27 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #28 0x7a9847 in ?? ??:0 #29 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #30 0x7ac2ea in ?? ??:0 #31 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #32 0x574668 in ?? ??:0 #33 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #34 0x5749fa in ?? ??:0 #35 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #36 0x573e9b in ?? ??:0 #37 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #38 0x66efe4 in ?? ??:0 #39 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #40 0x5745f0 in ?? ??:0 #41 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #42 0x7a7429 in ?? ??:0 #43 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #44 0x7995cc in ?? ??:0 #45 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #46 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #47 0x7a9847 in ?? ??:0 #48 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #49 0x7ac2ea in ?? ??:0 #50 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #51 0x574668 in ?? ??:0 #52 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #53 0x5749fa in ?? ??:0 #54 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #55 0x573e9b in ?? ??:0 #56 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #57 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #58 0x793369 in ?? ??:0 #59 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #60 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #61 0x7a9847 in ?? ??:0 #62 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #63 0x7ac2ea in ?? ??:0 #64 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #65 0x574668 in ?? ??:0 #66 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #67 0x5749fa in ?? ??:0 #68 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #69 0x573e9b in ?? ??:0 #70 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #71 0x66efe4 in ?? ??:0 #72 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #73 0x5745f0 in ?? ??:0 #74 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #75 0x7a7429 in ?? ??:0 #76 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #77 0x7995cc in ?? ??:0 #78 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #79 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #80 0x7a9847 in ?? ??:0 #81 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #82 0x7ac2ea in ?? ??:0 #83 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #84 0x574668 in ?? ??:0 #85 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #86 0x5749fa in ?? ??:0 #87 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #88 0x573e9b in ?? ??:0 #89 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #90 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #91 0x793369 in ?? ??:0 #92 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #93 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #94 0x7a9847 in ?? ??:0 #95 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #96 0x7ac2ea in ?? ??:0 #97 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #98 0x574668 in ?? ??:0 #99 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #100 0x5749fa in ?? ??:0 #101 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #102 0x573e9b in ?? ??:0 #103 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #104 0x66efe4 in ?? ??:0 #105 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #106 0x5745f0 in ?? ??:0 #107 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #108 0x7a7429 in ?? ??:0 #109 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #110 0x7995cc in ?? ??:0 #111 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #112 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #113 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #114 0x7ab4cb in ?? ??:0 #115 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #116 0x7a76f2 in ?? ??:0 #117 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #118 0x7995cc in ?? ??:0 #119 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #120 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #121 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #122 0x7ab4cb in ?? ??:0 #123 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #124 0x7a76f2 in ?? ??:0 #125 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #126 0x7995cc in ?? ??:0 #127 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #128 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #129 0x7a9847 in ?? ??:0 #130 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #131 0x7ac2ea in ?? ??:0 #132 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #133 0x574668 in ?? ??:0 #134 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #135 0x5749fa in ?? ??:0 #136 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #137 0x573e9b in ?? ??:0 #138 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #139 0x6713f8 in ?? ??:0 #140 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #141 0x666d8d in ?? ??:0 #142 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #143 0x5745f0 in ?? ??:0 #144 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #145 0x7a7429 in ?? ??:0 #146 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #147 0x7995cc in ?? ??:0 #148 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #149 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #150 0x7a9847 in ?? ??:0 #151 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #152 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #153 0x78e0df in ?? ??:0 #154 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #155 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #156 0x5142f5 in ?? ??:0 #157 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #158 0x512afa in ?? ??:0 #159 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #160 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #161 0x53eefd in ?? ??:0 #162 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #163 0x503d16 in ?? ??:0 #164 0x7f86ccc5d82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #165 0x7f86ccc5d82f in ?? ??:0 #166 0x432548 in _start ??:? #167 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x63acfd) ==18600==ABORTING ---------- components: Interpreter Core files: obj_1088 messages: 287337 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x0005ffff800d type: security versions: Python 3.6 Added file: http://bugs.python.org/file46593/obj_1088 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:56:18 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:56:18 +0000 Subject: [New-bugs-announce] [issue29499] AddressSanitizer: SEGV on unknown address 0x000ebfff800d Message-ID: <1486565778.73.0.558630262267.issue29499@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. _PyObject_Alloc (ctx=0x0, elsize=136, nelem=1, use_calloc=0) at Objects/obmalloc.c:1258 1258 if ((pool->freeblock = *(block **)bp) != NULL) { Description: Access violation on source operand Short description: SourceAv (19/22) Hash: 931f1ff7977aaf47bb64eec6d074074f.3e2cbb794853bcf6a077da4bfa99ade4 Exploitability Classification: UNKNOWN Explanation: The target crashed on an access violation at an address matching the source operand of the current instruction. This likely indicates a read access violation. Other tags: AccessViolation (21/22) ASAN: EsEASAN:DEADLYSIGNAL ================================================================= ==18115==ERROR: AddressSanitizer: SEGV on unknown address 0x000ebfff800d (pc 0x0000005082ed bp 0x00720000006f sp 0x7fffe2536f60 T0) #0 0x5082ec in _PyObject_Alloc /home/test/check/PythonASAN/Objects/obmalloc.c:1258 #1 0x5082ec in ?? ??:0 #2 0x54318c in _PyObject_GC_Alloc /home/test/check/PythonASAN/Modules/gcmodule.c:1714 #3 0x54318c in ?? ??:0 #4 0x543391 in _PyObject_GC_Malloc /home/test/check/PythonASAN/Modules/gcmodule.c:1736 #5 0x543391 in _PyObject_GC_New /home/test/check/PythonASAN/Modules/gcmodule.c:1748 #6 0x543391 in ?? ??:0 #7 0x5d5516 in PyFunction_NewWithQualName /home/test/check/PythonASAN/Objects/funcobject.c:21 #8 0x5d5516 in ?? ??:0 #9 0x796ecf in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3373 #10 0x796ecf in ?? ??:0 #11 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #12 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #13 0x7a9847 in ?? ??:0 #14 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #15 0x7ab648 in ?? ??:0 #16 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #17 0x7a76f2 in ?? ??:0 #18 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #19 0x7995cc in ?? ??:0 #20 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #21 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #22 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #23 0x7ab4cb in ?? ??:0 #24 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #25 0x7a76f2 in ?? ??:0 #26 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #27 0x7995cc in ?? ??:0 #28 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #29 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #30 0x7a9847 in ?? ??:0 #31 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #32 0x7ab648 in ?? ??:0 #33 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #34 0x7a76f2 in ?? ??:0 #35 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #36 0x7995cc in ?? ??:0 #37 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #38 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #39 0x7a9847 in ?? ??:0 #40 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #41 0x7ab648 in ?? ??:0 #42 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #43 0x7a76f2 in ?? ??:0 #44 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #45 0x7995cc in ?? ??:0 #46 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #47 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #48 0x7a9847 in ?? ??:0 #49 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #50 0x7ab648 in ?? ??:0 #51 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #52 0x7a76f2 in ?? ??:0 #53 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #54 0x7995cc in ?? ??:0 #55 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #56 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #57 0x7a9847 in ?? ??:0 #58 0x78e15d in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #59 0x78e15d in ?? ??:0 #60 0x5d6d7d in function_call /home/test/check/PythonASAN/Objects/funcobject.c:604 #61 0x5d6d7d in ?? ??:0 #62 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #63 0x573e9b in ?? ??:0 #64 0x92ce4e in property_descr_get /home/test/check/PythonASAN/Objects/descrobject.c:1384 #65 0x92ce4e in ?? ??:0 #66 0x63ac07 in _PyObject_GenericGetAttrWithDict /home/test/check/PythonASAN/Objects/object.c:1060 #67 0x63ac07 in ?? ??:0 #68 0x7966cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:2815 (discriminator 1) #69 0x7966cc in ?? ??:0 #70 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #71 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #72 0x7a9847 in ?? ??:0 #73 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #74 0x7ab648 in ?? ??:0 #75 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #76 0x7a76f2 in ?? ??:0 #77 0x792b47 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3291 #78 0x792b47 in ?? ??:0 #79 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #80 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #81 0x7a9847 in ?? ??:0 #82 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #83 0x7ac2ea in ?? ??:0 #84 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #85 0x574668 in ?? ??:0 #86 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #87 0x5749fa in ?? ??:0 #88 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #89 0x573e9b in ?? ??:0 #90 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #91 0x6713f8 in ?? ??:0 #92 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #93 0x666d8d in ?? ??:0 #94 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #95 0x5745f0 in ?? ??:0 #96 0x574ff3 in _PyObject_FastCallKeywords /home/test/check/PythonASAN/Objects/abstract.c:2480 #97 0x574ff3 in ?? ??:0 #98 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #99 0x7a7429 in ?? ??:0 #100 0x792b47 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3291 #101 0x792b47 in ?? ??:0 #102 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #103 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #104 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #105 0x7ab4cb in ?? ??:0 #106 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #107 0x7a76f2 in ?? ??:0 #108 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #109 0x7995cc in ?? ??:0 #110 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #111 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #112 0x7a9847 in ?? ??:0 #113 0x78e15d in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #114 0x78e15d in ?? ??:0 #115 0x5d6d7d in function_call /home/test/check/PythonASAN/Objects/funcobject.c:604 #116 0x5d6d7d in ?? ??:0 #117 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #118 0x573e9b in ?? ??:0 #119 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #120 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #121 0x793369 in ?? ??:0 #122 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #123 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #124 0x7a9847 in ?? ??:0 #125 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #126 0x7ab648 in ?? ??:0 #127 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #128 0x7a76f2 in ?? ??:0 #129 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #130 0x7995cc in ?? ??:0 #131 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #132 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #133 0x7a9847 in ?? ??:0 #134 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #135 0x7ab648 in ?? ??:0 #136 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #137 0x7a76f2 in ?? ??:0 #138 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #139 0x7995cc in ?? ??:0 #140 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #141 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #142 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #143 0x7ab4cb in ?? ??:0 #144 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #145 0x7a76f2 in ?? ??:0 #146 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #147 0x7995cc in ?? ??:0 #148 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #149 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #150 0x7a9847 in ?? ??:0 #151 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #152 0x7ac2ea in ?? ??:0 #153 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #154 0x574668 in ?? ??:0 #155 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #156 0x5749fa in ?? ??:0 #157 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #158 0x573e9b in ?? ??:0 #159 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #160 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #161 0x793369 in ?? ??:0 #162 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #163 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #164 0x7a9847 in ?? ??:0 #165 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #166 0x7ac2ea in ?? ??:0 #167 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #168 0x574668 in ?? ??:0 #169 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #170 0x5749fa in ?? ??:0 #171 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #172 0x573e9b in ?? ??:0 #173 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #174 0x66efe4 in ?? ??:0 #175 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #176 0x5745f0 in ?? ??:0 #177 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #178 0x7a7429 in ?? ??:0 #179 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #180 0x7995cc in ?? ??:0 #181 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #182 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #183 0x7a9847 in ?? ??:0 #184 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #185 0x7ac2ea in ?? ??:0 #186 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #187 0x574668 in ?? ??:0 #188 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #189 0x5749fa in ?? ??:0 #190 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #191 0x573e9b in ?? ??:0 #192 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #193 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #194 0x793369 in ?? ??:0 #195 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #196 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #197 0x7a9847 in ?? ??:0 #198 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #199 0x7ac2ea in ?? ??:0 #200 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #201 0x574668 in ?? ??:0 #202 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #203 0x5749fa in ?? ??:0 #204 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #205 0x573e9b in ?? ??:0 #206 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #207 0x66efe4 in ?? ??:0 #208 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #209 0x5745f0 in ?? ??:0 #210 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #211 0x7a7429 in ?? ??:0 #212 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #213 0x7995cc in ?? ??:0 #214 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #215 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #216 0x7a9847 in ?? ??:0 #217 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #218 0x7ac2ea in ?? ??:0 #219 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #220 0x574668 in ?? ??:0 #221 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #222 0x5749fa in ?? ??:0 #223 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #224 0x573e9b in ?? ??:0 #225 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #226 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #227 0x793369 in ?? ??:0 #228 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #229 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #230 0x7a9847 in ?? ??:0 #231 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #232 0x7ac2ea in ?? ??:0 #233 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #234 0x574668 in ?? ??:0 #235 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #236 0x5749fa in ?? ??:0 #237 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #238 0x573e9b in ?? ??:0 #239 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #240 0x66efe4 in ?? ??:0 #241 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #242 0x5745f0 in ?? ??:0 #243 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #244 0x7a7429 in ?? ??:0 #245 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #246 0x7995cc in ?? ??:0 #247 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #248 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #249 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #250 0x7ab4cb in ?? ??:0 #251 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #252 0x7a76f2 in ?? ??:0 #253 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #254 0x7995cc in ?? ??:0 #255 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #256 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #257 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #258 0x7ab4cb in ?? ??:0 #259 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #260 0x7a76f2 in ?? ??:0 #261 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #262 0x7995cc in ?? ??:0 #263 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #264 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #265 0x7a9847 in ?? ??:0 #266 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #267 0x7ac2ea in ?? ??:0 #268 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #269 0x574668 in ?? ??:0 #270 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #271 0x5749fa in ?? ??:0 #272 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #273 0x573e9b in ?? ??:0 #274 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #275 0x6713f8 in ?? ??:0 #276 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #277 0x666d8d in ?? ??:0 #278 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #279 0x5745f0 in ?? ??:0 #280 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #281 0x7a7429 in ?? ??:0 #282 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #283 0x7995cc in ?? ??:0 #284 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #285 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #286 0x7a9847 in ?? ??:0 #287 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #288 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #289 0x78e0df in ?? ??:0 #290 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #291 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #292 0x5142f5 in ?? ??:0 #293 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #294 0x512afa in ?? ??:0 #295 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #296 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #297 0x53eefd in ?? ??:0 #298 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #299 0x503d16 in ?? ??:0 #300 0x7f8e75bb582f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #301 0x7f8e75bb582f in ?? ??:0 #302 0x432548 in _start ??:? #303 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/home/test/check/PythonASAN/python+0x5082ec) ==18115==ABORTING ---------- components: Interpreter Core files: obmalloc_1258 messages: 287338 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x000ebfff800d type: security versions: Python 3.6 Added file: http://bugs.python.org/file46594/obmalloc_1258 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:57:10 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:57:10 +0000 Subject: [New-bugs-announce] [issue29500] AddressSanitizer: heap-buffer-overflow on address 0x61600004a982 Message-ID: <1486565830.16.0.885734868049.issue29500@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Inferior 1 (process 19456) exited normally] ASAN: ================================================================= ==18010==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61600004a982 at pc 0x000000830a11 bp 0x7fff6131b9b0 sp 0x7fff6131b9a8 READ of size 2 at 0x61600004a982 thread T0 #0 0x830a10 in find_op /home/test/check/PythonASAN/Python/peephole.c:101 (discriminator 1) #1 0x830a10 in PyCode_Optimize /home/test/check/PythonASAN/Python/peephole.c:712 (discriminator 1) #2 0x830a10 in ?? ??:0 #3 0x7ccf6c in makecode /home/test/check/PythonASAN/Python/compile.c:5249 #4 0x7ccf6c in assemble /home/test/check/PythonASAN/Python/compile.c:5367 #5 0x7ccf6c in ?? ??:0 #6 0x7d0a09 in compiler_function /home/test/check/PythonASAN/Python/compile.c:1886 #7 0x7d0a09 in ?? ??:0 #8 0x7b0923 in compiler_body /home/test/check/PythonASAN/Python/compile.c:1463 #9 0x7b0923 in ?? ??:0 #10 0x7ae107 in compiler_mod /home/test/check/PythonASAN/Python/compile.c:1483 #11 0x7ae107 in PyAST_CompileObject /home/test/check/PythonASAN/Python/compile.c:341 #12 0x7ae107 in ?? ??:0 #13 0x5142d8 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:977 #14 0x5142d8 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #15 0x5142d8 in ?? ??:0 #16 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #17 0x512afa in ?? ??:0 #18 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #19 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #20 0x53eefd in ?? ??:0 #21 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #22 0x503d16 in ?? ??:0 #23 0x7f5554ba782f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #24 0x7f5554ba782f in ?? ??:0 #25 0x432548 in _start ??:? #26 0x432548 in ?? ??:0 0x61600004a982 is located 0 bytes to the right of 514-byte region [0x61600004a780,0x61600004a982) allocated by thread T0 here: #0 0x4d2678 in malloc ??:? #1 0x4d2678 in ?? ??:0 #2 0x508c35 in PyMem_RawMalloc /home/test/check/PythonASAN/Objects/obmalloc.c:386 #3 0x508c35 in _PyObject_Alloc /home/test/check/PythonASAN/Objects/obmalloc.c:1427 #4 0x508c35 in ?? ??:0 SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/test/check/PythonASAN/python+0x830a10) Shadow bytes around the buggy address: 0x0c2c800014e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c800014f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c80001500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c80001510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c80001520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c2c80001530:[02]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c80001540: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2c80001550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c80001560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c80001570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2c80001580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==18010==ABORTING ---------- components: Interpreter Core files: peephole_101 messages: 287339 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: heap-buffer-overflow on address 0x61600004a982 type: security versions: Python 3.6 Added file: http://bugs.python.org/file46595/peephole_101 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 09:57:54 2017 From: report at bugs.python.org (BeginVuln) Date: Wed, 08 Feb 2017 14:57:54 +0000 Subject: [New-bugs-announce] [issue29501] AddressSanitizer: SEGV on unknown address 0x0000000028cb Message-ID: <1486565874.81.0.128719869317.issue29501@psf.upfronthosting.co.za> New submission from BeginVuln: OS Version : Ubuntu 16.04 LTS Python download link : https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz Python version : 3.6.0 Normal build cmd : ./configure make Asan build cmd: export CC="/usr/bin/clang -fsanitize=address export CXX="/usr/bin/clang++ -fsanitize=address ./confiugre make GDB with exploitable: To enable execution of this file add add-auto-load-safe-path /home/test/check/PythonGDB/python-gdb.py line to your configuration file "/home/test/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/test/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. strlen () at ../sysdeps/x86_64/strlen.S:106 Description: Access violation near NULL on source operand Short description: SourceAvNearNull (16/22) Hash: 887855ab5f56908afba8d62b6a25a6db.02c83d5748e9f8196679750a04737f93 Exploitability Classification: PROBABLY_NOT_EXPLOITABLE Explanation: The target crashed on an access violation at an address matching the source operand of the current instruction. This likely indicates a read access violation, which may mean the application crashed on a simple NULL dereference to data structure that has no immediate effect on control of the processor. Other tags: AccessViolation (21/22) ASAN: sEASAN:DEADLYSIGNAL ================================================================= ==18621==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000028cb (pc 0x7f1572e57d16 bp 0x7ffeaf5703d0 sp 0x7ffeaf56fb68 T0) #0 0x7f1572e57d15 in strlen /build/glibc-GKVZIf/glibc-2.23/string/../sysdeps/x86_64/strlen.S:76 #1 0x7f1572e57d15 in ?? ??:0 #2 0x44ffac in __interceptor_strlen.part.45 asan_interceptors.cc.o:? #3 0x44ffac in ?? ??:0 #4 0x7f156c4cdf5c in string_at /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:5226 #5 0x7f156c4cdf5c in ?? ??:0 #6 0x7f156c2ade3f in ffi_call_unix64 ??:? #7 0x7f156c2ade3f in ?? ??:0 #8 0x7f156c2ad8aa in ffi_call ??:? #9 0x7f156c2ad8aa in ?? ??:0 #10 0x7f156c4db311 in _call_function_pointer /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:809 #11 0x7f156c4db311 in _ctypes_callproc /home/test/check/PythonASAN/Modules/_ctypes/callproc.c:1147 #12 0x7f156c4db311 in ?? ??:0 #13 0x7f156c4ca199 in PyCFuncPtr_call /home/test/check/PythonASAN/Modules/_ctypes/_ctypes.c:3870 #14 0x7f156c4ca199 in ?? ??:0 #15 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #16 0x5745f0 in ?? ??:0 #17 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #18 0x7a7429 in ?? ??:0 #19 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #20 0x7995cc in ?? ??:0 #21 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #22 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #23 0x7a9847 in ?? ??:0 #24 0x7ab648 in fast_function /home/test/check/PythonASAN/Python/ceval.c:4929 (discriminator 1) #25 0x7ab648 in ?? ??:0 #26 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #27 0x7a76f2 in ?? ??:0 #28 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #29 0x7995cc in ?? ??:0 #30 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #31 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #32 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #33 0x7ab4cb in ?? ??:0 #34 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #35 0x7a76f2 in ?? ??:0 #36 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #37 0x7995cc in ?? ??:0 #38 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #39 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #40 0x7a9847 in ?? ??:0 #41 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #42 0x7ac2ea in ?? ??:0 #43 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #44 0x574668 in ?? ??:0 #45 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #46 0x5749fa in ?? ??:0 #47 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #48 0x573e9b in ?? ??:0 #49 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #50 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #51 0x793369 in ?? ??:0 #52 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #53 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #54 0x7a9847 in ?? ??:0 #55 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #56 0x7ac2ea in ?? ??:0 #57 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #58 0x574668 in ?? ??:0 #59 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #60 0x5749fa in ?? ??:0 #61 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #62 0x573e9b in ?? ??:0 #63 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #64 0x66efe4 in ?? ??:0 #65 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #66 0x5745f0 in ?? ??:0 #67 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #68 0x7a7429 in ?? ??:0 #69 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #70 0x7995cc in ?? ??:0 #71 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #72 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #73 0x7a9847 in ?? ??:0 #74 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #75 0x7ac2ea in ?? ??:0 #76 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #77 0x574668 in ?? ??:0 #78 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #79 0x5749fa in ?? ??:0 #80 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #81 0x573e9b in ?? ??:0 #82 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #83 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #84 0x793369 in ?? ??:0 #85 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #86 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #87 0x7a9847 in ?? ??:0 #88 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #89 0x7ac2ea in ?? ??:0 #90 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #91 0x574668 in ?? ??:0 #92 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #93 0x5749fa in ?? ??:0 #94 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #95 0x573e9b in ?? ??:0 #96 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #97 0x66efe4 in ?? ??:0 #98 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #99 0x5745f0 in ?? ??:0 #100 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #101 0x7a7429 in ?? ??:0 #102 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #103 0x7995cc in ?? ??:0 #104 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #105 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #106 0x7a9847 in ?? ??:0 #107 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #108 0x7ac2ea in ?? ??:0 #109 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #110 0x574668 in ?? ??:0 #111 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #112 0x5749fa in ?? ??:0 #113 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #114 0x573e9b in ?? ??:0 #115 0x793369 in do_call_core /home/test/check/PythonASAN/Python/ceval.c:5057 #116 0x793369 in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3357 #117 0x793369 in ?? ??:0 #118 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #119 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #120 0x7a9847 in ?? ??:0 #121 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #122 0x7ac2ea in ?? ??:0 #123 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #124 0x574668 in ?? ??:0 #125 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #126 0x5749fa in ?? ??:0 #127 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #128 0x573e9b in ?? ??:0 #129 0x66efe4 in slot_tp_call /home/test/check/PythonASAN/Objects/typeobject.c:6167 #130 0x66efe4 in ?? ??:0 #131 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #132 0x5745f0 in ?? ??:0 #133 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #134 0x7a7429 in ?? ??:0 #135 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #136 0x7995cc in ?? ??:0 #137 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #138 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #139 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #140 0x7ab4cb in ?? ??:0 #141 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #142 0x7a76f2 in ?? ??:0 #143 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #144 0x7995cc in ?? ??:0 #145 0x7ab4cb in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #146 0x7ab4cb in _PyFunction_FastCall /home/test/check/PythonASAN/Python/ceval.c:4870 #147 0x7ab4cb in fast_function /home/test/check/PythonASAN/Python/ceval.c:4905 #148 0x7ab4cb in ?? ??:0 #149 0x7a76f2 in call_function /home/test/check/PythonASAN/Python/ceval.c:4809 #150 0x7a76f2 in ?? ??:0 #151 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #152 0x7995cc in ?? ??:0 #153 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #154 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #155 0x7a9847 in ?? ??:0 #156 0x7ac2ea in _PyFunction_FastCallDict /home/test/check/PythonASAN/Python/ceval.c:5021 #157 0x7ac2ea in ?? ??:0 #158 0x574668 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2295 #159 0x574668 in ?? ??:0 #160 0x5749fa in _PyObject_Call_Prepend /home/test/check/PythonASAN/Objects/abstract.c:2358 #161 0x5749fa in ?? ??:0 #162 0x573e9b in PyObject_Call /home/test/check/PythonASAN/Objects/abstract.c:2246 #163 0x573e9b in ?? ??:0 #164 0x6713f8 in slot_tp_init /home/test/check/PythonASAN/Objects/typeobject.c:6380 #165 0x6713f8 in ?? ??:0 #166 0x666d8d in type_call /home/test/check/PythonASAN/Objects/typeobject.c:915 (discriminator 1) #167 0x666d8d in ?? ??:0 #168 0x5745f0 in _PyObject_FastCallDict /home/test/check/PythonASAN/Objects/abstract.c:2316 #169 0x5745f0 in ?? ??:0 #170 0x7a7429 in call_function /home/test/check/PythonASAN/Python/ceval.c:4812 #171 0x7a7429 in ?? ??:0 #172 0x7995cc in _PyEval_EvalFrameDefault /home/test/check/PythonASAN/Python/ceval.c:3275 #173 0x7995cc in ?? ??:0 #174 0x7a9847 in PyEval_EvalFrameEx /home/test/check/PythonASAN/Python/ceval.c:718 #175 0x7a9847 in _PyEval_EvalCodeWithName /home/test/check/PythonASAN/Python/ceval.c:4119 #176 0x7a9847 in ?? ??:0 #177 0x78e0df in PyEval_EvalCodeEx /home/test/check/PythonASAN/Python/ceval.c:4140 #178 0x78e0df in PyEval_EvalCode /home/test/check/PythonASAN/Python/ceval.c:695 #179 0x78e0df in ?? ??:0 #180 0x5142f5 in run_mod /home/test/check/PythonASAN/Python/pythonrun.c:980 #181 0x5142f5 in PyRun_FileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:933 #182 0x5142f5 in ?? ??:0 #183 0x512afa in PyRun_SimpleFileExFlags /home/test/check/PythonASAN/Python/pythonrun.c:396 #184 0x512afa in ?? ??:0 #185 0x53eefd in run_file /home/test/check/PythonASAN/Modules/main.c:320 #186 0x53eefd in Py_Main /home/test/check/PythonASAN/Modules/main.c:780 #187 0x53eefd in ?? ??:0 #188 0x503d16 in main /home/test/check/PythonASAN/./Programs/python.c:69 #189 0x503d16 in ?? ??:0 #190 0x7f1572ded82f in __libc_start_main /build/glibc-GKVZIf/glibc-2.23/csu/../csu/libc-start.c:291 #191 0x7f1572ded82f in ?? ??:0 #192 0x432548 in _start ??:? #193 0x432548 in ?? ??:0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x8ad15) ==18621==ABORTING ---------- components: Interpreter Core files: strlen_76 messages: 287340 nosy: beginvuln priority: normal severity: normal status: open title: AddressSanitizer: SEGV on unknown address 0x0000000028cb type: security versions: Python 3.6 Added file: http://bugs.python.org/file46596/strlen_76 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 10:39:38 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Feb 2017 15:39:38 +0000 Subject: [New-bugs-announce] [issue29502] Should PyObject_Call() call the profiler on C functions, use C_TRACE() macro? Message-ID: <1486568378.9.0.904847418882.issue29502@psf.upfronthosting.co.za> New submission from STINNER Victor: call_function() and do_call_core() functions of Python/ceval.c use C_TRACE() macro to call the profiler, but PyObject_Call() and similar functions like _PyObject_FastCallKeywords() don't. Is it a bug or a deliberate choice for performance? Since PyObject_Call() and similar functions have now fast paths, I don't think that it's still needed to have these fast paths in ceval.c too. But I kept fast paths in ceval.c because of C_TRACE(). ---------- components: Interpreter Core messages: 287343 nosy: haypo, inada.naoki, serhiy.storchaka priority: normal severity: normal status: open title: Should PyObject_Call() call the profiler on C functions, use C_TRACE() macro? type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 10:53:16 2017 From: report at bugs.python.org (Andi Bergmeier) Date: Wed, 08 Feb 2017 15:53:16 +0000 Subject: [New-bugs-announce] [issue29503] Make embedded-Python detectable Message-ID: <1486569196.65.0.6151718591.issue29503@psf.upfronthosting.co.za> New submission from Andi Bergmeier: While it is nice to have embeddable Python for Windows, currently there seems to be no way of distinguishing it from a "normal" Python, which reacts quite differently to its Environment. Would like to support Embeddable Python (and ._pth), but really first need a way of identifying whether it is embeddable or not. ---------- components: Windows messages: 287344 nosy: Andi Bergmeier, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Make embedded-Python detectable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 12:29:23 2017 From: report at bugs.python.org (Mike Gilbert) Date: Wed, 08 Feb 2017 17:29:23 +0000 Subject: [New-bugs-announce] [issue29504] blake2: compile error with -march=bdver2 Message-ID: <1486574963.2.0.72017577066.issue29504@psf.upfronthosting.co.za> New submission from Mike Gilbert: When compiling python-3.6.0 with -march=bdver2, the blake2 module fails to build. In file included from /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s-round.h:70:0, from /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s.c:40, from /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/blake2s_impl.c:32: /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s-load-xop.h:29:4: error: expected identifier or '(' before 'return' return _mm_blendv_epi8(t0, s1, mask); ^ /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s-load-xop.h:30:1: error: expected identifier or '(' before '}' token }*/ ^ /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s-load-xop.h:30:3: error: expected identifier or '(' before '/' token }*/ ^ In file included from /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/blake2s_impl.c:32:0: /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s.c: In function 'blake2s_init0': /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s.c:167:38: error: 'blake2s_IV' undeclared (first use in this function) for( i = 0; i < 8; ++i ) S->h[i] = blake2s_IV[i]; ^ /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s.c:167:38: note: each undeclared identifier is reported only once for each function it appears in /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s.c: In function 'PyBlake2_blake2s_init_param': /var/tmp/portage/dev-lang/python-3.6.0/work/Python-3.6.0/Modules/_blake2/impl/blake2s.c:176:44: error: 'blake2s_IV' undeclared (first use in this function) const uint8_t * v = ( const uint8_t * )( blake2s_IV ); ^ ---------- components: Extension Modules files: build.log messages: 287356 nosy: floppymaster priority: normal severity: normal status: open title: blake2: compile error with -march=bdver2 versions: Python 3.6 Added file: http://bugs.python.org/file46598/build.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 15:54:21 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 08 Feb 2017 20:54:21 +0000 Subject: [New-bugs-announce] [issue29505] Submit the re, json, & csv modules to oss-fuzz testing Message-ID: <1486587261.97.0.342323514088.issue29505@psf.upfronthosting.co.za> New submission from Gregory P. Smith: For reference, read https://github.com/google/oss-fuzz. We should investigate creating fuzz targets for the Python re module (_sre.c) at a minimum. There are probably other good targets as well such as _json.c and _csv.c. pickle and marshal are not intended to be secure so ignore those. ---------- messages: 287363 nosy: gregory.p.smith priority: normal severity: normal stage: test needed status: open title: Submit the re, json, & csv modules to oss-fuzz testing type: security versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 17:02:44 2017 From: report at bugs.python.org (Pedro) Date: Wed, 08 Feb 2017 22:02:44 +0000 Subject: [New-bugs-announce] [issue29506] Incorrect documentation for the copy module Message-ID: <1486591364.1.0.297030175166.issue29506@psf.upfronthosting.co.za> New submission from Pedro: The docs for the copy module contain a bullet that says the following: "Because deep copy copies everything it may copy too much, e.g., even administrative data structures that should be shared even between copies." There should be a "not" between "should" and "be shared." I think the second "even" can be dropped, too. ---------- assignee: docs at python components: Documentation messages: 287367 nosy: docs at python, pgacv2 priority: normal severity: normal status: open title: Incorrect documentation for the copy module versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 19:17:38 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 00:17:38 +0000 Subject: [New-bugs-announce] [issue29507] Use FASTCALL in call_method() to avoid temporary tuple Message-ID: <1486599458.19.0.87442756928.issue29507@psf.upfronthosting.co.za> New submission from STINNER Victor: Subset of the (almost) rejected issue #29259 (tp_fastcall), attached patch adds _PyMethod_FastCall() and uses it in call_method() of typeobject.c. The change avoids the creation of a temporary tuple for Python functions and METH_FASTCALL C functions. Currently, call_method() calls method_call() which calls _PyObject_Call_Prepend(), and calling method_call() requires a tuple for positional arguments. Example of benchmark on __getitem__(): 1.3x faster (-22%). $ ./python -m perf timeit -s 'class C:' -s ' def __getitem__(self, index): return index' -s 'c=C()' 'c[0]' Median +- std dev: 130 ns +- 1 ns => 102 ns +- 1 ns See also the issue #29263 "Implement LOAD_METHOD/CALL_METHOD for C functions". ---------- components: Interpreter Core files: method_fastcall.patch keywords: patch messages: 287371 nosy: haypo, inada.naoki, serhiy.storchaka priority: normal severity: normal status: open title: Use FASTCALL in call_method() to avoid temporary tuple type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46601/method_fastcall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 8 22:22:05 2017 From: report at bugs.python.org (Michael Rieck) Date: Thu, 09 Feb 2017 03:22:05 +0000 Subject: [New-bugs-announce] [issue29508] Cannot install python-3.2.5 on Mac 10.11.6 Message-ID: <1486610525.23.0.51102827646.issue29508@psf.upfronthosting.co.za> New submission from Michael Rieck: python-3.2.5-macosx10.6.dmg starts installation on my Mac 10.11.6 but terminates at end with following message: The Installation Failed. The installer could not install the software because there was no software to install. I cold booted my computer, tried again, and got the same results. ---------- components: Installation messages: 287381 nosy: rieck priority: normal severity: normal status: open title: Cannot install python-3.2.5 on Mac 10.11.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 02:48:43 2017 From: report at bugs.python.org (INADA Naoki) Date: Thu, 09 Feb 2017 07:48:43 +0000 Subject: [New-bugs-announce] [issue29509] redundant interning in PyObject_GetAttrString Message-ID: <1486626523.7.0.635584720165.issue29509@psf.upfronthosting.co.za> New submission from INADA Naoki: PyObject_GetAttrString creates temporary unicode object and intern it. It totally redundant. ---------- files: getattrstring-nointern.patch keywords: patch messages: 287386 nosy: inada.naoki priority: normal severity: normal stage: patch review status: open title: redundant interning in PyObject_GetAttrString type: performance versions: Python 3.7 Added file: http://bugs.python.org/file46602/getattrstring-nointern.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 03:24:53 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Thu, 09 Feb 2017 08:24:53 +0000 Subject: [New-bugs-announce] [issue29510] gitignore settings files for Eclipse IDE Message-ID: <1486628693.8.0.0671734505293.issue29510@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: The Eclipse IDE, and its relatives pydev and LiClipse, store settings in the root of a repository. It would be nice for the master .gitignore file to ignore these files, so that individual developers don't have to do this. I am preparing a GitHub Pull Request that fixes this issue. It is a matter of adding 4 lines to the top-level .gitignore file. ---------- messages: 287388 nosy: JDLH priority: normal severity: normal status: open title: gitignore settings files for Eclipse IDE versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 04:17:00 2017 From: report at bugs.python.org (George Shuklin) Date: Thu, 09 Feb 2017 09:17:00 +0000 Subject: [New-bugs-announce] [issue29511] Add 'find' as build-in method for lists Message-ID: <1486631820.8.0.066823653416.issue29511@psf.upfronthosting.co.za> New submission from George Shuklin: I found that Python provides 'find()' and 'in' methods for strings, but lacking same functionality for lists. Because strings and lists are very similar, it's reasonable to expect same function available for both. Here long and rather ugly hack list on stackoverflow about 'reinventing the wheel': http://stackoverflow.com/questions/16579085/python-verifying-if-one-list-is-a-subset-of-the-other There are short few proposals, each of them imperfect: 1. Use sets intersection. This looses count and order 2. Use collections.Count. This looses order 3. all(x in two for x in one) - looses order Propsal: adds a normal 'find' method which will behave the same way as find for strings. It should perform normal __cmp__ call on each element, or, may be, asking for optional lambda to perform comparison of elements. ---------- components: Interpreter Core messages: 287394 nosy: george-shuklin priority: normal severity: normal status: open title: Add 'find' as build-in method for lists type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 06:46:03 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 11:46:03 +0000 Subject: [New-bugs-announce] [issue29512] regrtest refleak: implement bisection feature Message-ID: <1486640763.77.0.630012847727.issue29512@psf.upfronthosting.co.za> New submission from STINNER Victor: It would be great to be able to list which methods cause a reference leak. Example right now on the 3.6 branch: ---- $ ./python -m test -R 3:3 test_os Run tests sequentially 0:00:00 [1/1] test_os beginning 6 repetitions 123456 ...... test_os leaked [124, 124, 124] references, sum=372 test_os leaked [114, 114, 114] memory blocks, sum=342 test_os failed in 32 sec 1 test failed: test_os Total duration: 32 sec Tests result: FAILURE ---- Which methods caused the refleak? Is it possible to list test methods of a test file using unittest? ---------- components: Tests messages: 287405 nosy: haypo priority: normal severity: normal status: open title: regrtest refleak: implement bisection feature type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 07:09:14 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Feb 2017 12:09:14 +0000 Subject: [New-bugs-announce] [issue29513] os.scandir(str) reference leak (test_os refleak) Message-ID: <1486642154.55.0.56262059852.issue29513@psf.upfronthosting.co.za> New submission from STINNER Victor: The following code leaks one reference on Python 3.6: def test_attributes(self): d = dict((entry.name, entry) for entry in os.scandir('.')) Or try the command: ./python -m test -R 3:3 test_os -v -m test_attributes ---------- components: Library (Lib) messages: 287409 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: os.scandir(str) reference leak (test_os refleak) type: resource usage versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 10:30:10 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Feb 2017 15:30:10 +0000 Subject: [New-bugs-announce] [issue29514] Add a test case that prevents magic number changes in minor releases Message-ID: <1486654210.44.0.116789566768.issue29514@psf.upfronthosting.co.za> New submission from Nick Coghlan: The magic number change in 3.5.3 broke the world when Fedora attempted to rebase from 3.5.2, but upstream CPython developers don't currently get an automated notification that it isn't permitted to change the magic number in a maintenance release - instead, the current approach relies on people "just knowing" not to do that, and we just saw the limitations of relying on the code review process to catch this particular problem. I think we can keep this from happening again by having an importlib test case that fails if sys.version_info.releaselevel is "candidate" or "final" and either: - no "expected magic number" is defined; or - the actual magic number in importlib.util.MAGIC_NUMBER doesn't match the expected one The comments on the new test case would then explain the policy and why it isn't OK to break pyc file compatibility in a maintenance release. We'd also propose an update to the release PEP warning release managers to expect this error as part of prepping the first release candidate, and that they should lock in the magic number for the release at that time. ---------- messages: 287428 nosy: barry, brett.cannon, doko, encukou, ncoghlan priority: normal severity: normal status: open title: Add a test case that prevents magic number changes in minor releases versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 13:27:42 2017 From: report at bugs.python.org (Maximilian Hils) Date: Thu, 09 Feb 2017 18:27:42 +0000 Subject: [New-bugs-announce] [issue29515] socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows Message-ID: <1486664862.54.0.729311605676.issue29515@psf.upfronthosting.co.za> New submission from Maximilian Hils: The latest Windows builds for Python 3.5.3/3.6.0 do not export socket.IPPROTO_IPV6, even though e.g. socket.IPV6_V6ONLY is exported. This seems to be wrong to me as IPV6_V6ONLY requires the corresponding socket option level IPPROTO_IPV6 to be actually useful. The same issue at least also applies to IPPROTO_IPV4. christian.heimes mentioned that this is intended behaviour in https://bugs.python.org/issue6926 as Windows would not define the constants. Now I am all but an expert on this, but it seems to me that IPPROTO_IPV6 is defined in Windows: https://msdn.microsoft.com/en-us/library/windows/hardware/ff543746(v=vs.85).aspx. Apologies if I'm missing something here. Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32 bit (Intel)] on win32 >>> import socket; socket.IPPROTO_IPV6 Traceback (most recent call last): File "", line 1, in AttributeError: module 'socket' has no attribute 'IPPROTO_IPV6' As a workaround, IPPROTO_IPV6 can be substituted with the hardcoded constant 41. ---------- components: Windows messages: 287449 nosy: christian.heimes, mhils, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: socket module missing IPPROTO_IPV6, IPPROTO_IPV4 on Windows type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 16:12:34 2017 From: report at bugs.python.org (Darko Poljak) Date: Thu, 09 Feb 2017 21:12:34 +0000 Subject: [New-bugs-announce] [issue29516] shutil.copytree(symlinks=True) fails when copying symlinks cross-device and there is no alternative Message-ID: <1486674754.67.0.62017119203.issue29516@psf.upfronthosting.co.za> New submission from Darko Poljak: shutil.copytree() always calls copystat() for symlinks. Copying symlink to another volume fails if some attributes cannot be set. And there is no alternative to bypass this as it can be done for files and directories using copy_function. By default copy_function equals copy2() which calls copystat(). There is also copy() available which calls copymode(). >From the copytree() source code one can see that for symlink copystat() is called in any case: if os.path.islink(srcname): linkto = os.readlink(srcname) if symlinks: # We can't just leave it to `copy_function` because legacy # code with a custom `copy_function` may rely on copytree # doing the right thing. os.symlink(linkto, dstname) copystat(srcname, dstname, follow_symlinks=not symlinks) An example is running inside a docker container with a zfs based volume mounted at /root/.cdist. Root filesytem with /tmp is also on zfs based container root-volume. And copying files with shutil.move which in this case uses copytree results in the following error: Traceback (most recent call last): File "/appenv/lib/python3.5/shutil.py", line 538, in move os.rename(src, real_dst) OSError: [Errno 18] Cross-device link: '/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data' -> '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/appenv/bin/cdist", line 94, in commandline() File "/appenv/bin/cdist", line 66, in commandline args.func(args) File "/appenv/lib/python3.5/site-packages/cdist/config.py", line 157, in commandline args, parallel=False) File "/appenv/lib/python3.5/site-packages/cdist/config.py", line 227, in onehost c.run() File "/appenv/lib/python3.5/site-packages/cdist/config.py", line 255, in run self.local.save_cache() File "/appenv/lib/python3.5/site-packages/cdist/exec/local.py", line 265, in save_cache shutil.move(self.base_path, destination) File "/appenv/lib/python3.5/shutil.py", line 549, in move symlinks=True) File "/appenv/lib/python3.5/shutil.py", line 353, in copytree raise Error(errors) shutil.Error: [('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/network', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/network', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/network'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/os', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/os', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/os'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/machine', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/machine', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/machine'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/init-system', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/init-system', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/init-system'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/interfaces', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/interfaces', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/interfaces'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/os_version', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/os_version', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/os_version'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/cpu_cores', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/cpu_cores', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/cpu_cores'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/lsb_description', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/lsb_description', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/lsb_description'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/machine_type', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/machine_type', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/machine_type'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/efi', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/efi', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/efi'"), ('/tmp/tmpuxb_jr3y/936a8745479046ce91a00ee3013fc9b8/data/conf/explorer/lsb_id', '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/lsb_id', "[Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/explorer/lsb_id'"), ... Using copy_function=copy instead of default copy2 does not solve the problem since for symlinks copytree() always uses copystat(). Concrete example which mimics copytree() code for symlink: (appenv) ~ # rm /root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/type/__hpc_syslog (appenv) ~ # python Python 3.5.2 (default, Dec 20 2016, 17:58:45) [GCC 5.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> src='/tmp/tmpoiwfrgvk/936a8745479046ce91a00ee3013fc9b8/data/conf/type/__hpc_syslog' >>> dst='/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/type/__hpc_syslog' >>> linkto = os.readlink(src) >>> os.symlink(linkto, dst) >>> os.stat(dst) os.stat_result(st_mode=16877, st_ino=955, st_dev=71, st_nlink=4, st_uid=65534, st_gid=65534, st_size=8, st_atime=1486540058, st_mtime=1485953153, st_ctime=1485953153) >>> import shutil >>> shutil.copystat(src, dst, follow_symlinks=False) Traceback (most recent call last): File "", line 1, in File "/appenv/lib/python3.5/shutil.py", line 197, in copystat lookup("chmod")(dst, mode, follow_symlinks=follow) OSError: [Errno 95] Not supported: '/root/.cdist/cache/936a8745479046ce91a00ee3013fc9b8/conf/type/__hpc_syslog' >>> ---------- components: Library (Lib) messages: 287455 nosy: poljakowski priority: normal severity: normal status: open title: shutil.copytree(symlinks=True) fails when copying symlinks cross-device and there is no alternative type: crash versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 16:41:25 2017 From: report at bugs.python.org (DAVID ALEJANDRO Pineda) Date: Thu, 09 Feb 2017 21:41:25 +0000 Subject: [New-bugs-announce] [issue29517] "Can't pickle local object" when uses functools.partial with method and args... Message-ID: <1486676485.08.0.362566272702.issue29517@psf.upfronthosting.co.za> New submission from DAVID ALEJANDRO Pineda: Hello. I'm working in a real time data collector project. I'm using asyncio and multiprocessing (run_in_executor). In python 3.5 worked fine but in python 3.6 not, gave to me this error: "Traceback (most recent call last): File "/usr/local/lib/python3.6/multiprocessing/queues.py", line 241, in _feed obj = _ForkingPickler.dumps(obj) File "/usr/local/lib/python3.6/multiprocessing/reduction.py", line 51, in dumps cls(buf, protocol).dump(obj) AttributeError: Can't pickle local object 'WeakSet.__init__.._remove' " I tracked and the problem is when i run some method in run_in_executor with the functools.partial. Before this version the system works fine. The main file is local.py (to run with local administration using a socket) And the engine is in engine.py The project (in development): https://gitlab.com/pineiden/collector ---------- components: asyncio files: code_with_bug.png messages: 287459 nosy: DAVID ALEJANDRO Pineda, gvanrossum, yselivanov priority: normal severity: normal status: open title: "Can't pickle local object" when uses functools.partial with method and args... type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46614/code_with_bug.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 21:47:38 2017 From: report at bugs.python.org (Justin McNiel) Date: Fri, 10 Feb 2017 02:47:38 +0000 Subject: [New-bugs-announce] [issue29518] 'for' loop not automatically breaking (index error on line of loop header) Message-ID: <1486694858.31.0.700200461576.issue29518@psf.upfronthosting.co.za> New submission from Justin McNiel: All for loops are refusing to break (Python 2.7.13) on win32 - only on execution of '.py' file an example would be:" for x in range(5): #Line 1 of main.py print x #Line 2 of main.py " and the resulting error would be:" File "pathToFile\main.py", line 1, in for x in range(5): IndexError: array index out of range " I also have 32-bit python 3.6 installed, but the default for opening '.py' files is python 2.7 This error happens on custom made generators too, but never in the interactive shell. ---------- components: Windows files: pythonError.png messages: 287473 nosy: Justin McNiel, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: 'for' loop not automatically breaking (index error on line of loop header) type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file46616/pythonError.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 9 23:35:06 2017 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 10 Feb 2017 04:35:06 +0000 Subject: [New-bugs-announce] [issue29519] weakref spewing exceptions during finalization when combined with multiprocessing Message-ID: <1486701306.85.0.363188055849.issue29519@psf.upfronthosting.co.za> New submission from ?ukasz Langa: Antoine, #28427 introduces a regression. When used with multiprocessing, the WeakValueDictionary in `multiprocessing.util._afterfork_registry` causes the `remove()` to be invoked during `atexit` and then `sys.meta_path` is None, lots of things is None, including the global `_remove_dead_weakref`. In effect, I'm getting spew like this: Exception ignored in: .remove at 0x7fb2b905e2f0> Traceback (most recent call last): File "/usr/local/fbcode/gcc-4.9-glibc-2.20-fb/lib/python3.6/weakref.py", line 112, in remove TypeError: 'NoneType' object is not callable Exception ignored in: .remove at 0x7fb2b905e2f0> Traceback (most recent call last): File "/usr/local/fbcode/gcc-4.9-glibc-2.20-fb/lib/python3.6/weakref.py", line 112, in remove TypeError: 'NoneType' object is not callable Exception ignored in: .remove at 0x7fb2b905e2f0> Traceback (most recent call last): File "/usr/local/fbcode/gcc-4.9-glibc-2.20-fb/lib/python3.6/weakref.py", line 112, in remove TypeError: 'NoneType' object is not callable Exception ignored in: .remove at 0x7fb2b905e2f0> Traceback (most recent call last): File "/usr/local/fbcode/gcc-4.9-glibc-2.20-fb/lib/python3.6/weakref.py", line 112, in remove TypeError: 'NoneType' object is not callable When debugged, this 'NoneType' is `_remove_dead_weakref` (weakref.py:117). I'm working on a smaller repro, unfortunately this happens as part of a rather large multiprocessing app so this might take a while. Just wanted to let you know, maybe you'll know right away what the problem is. ---------- assignee: pitrou components: Library (Lib) keywords: 3.5regression, 3.6regression messages: 287475 nosy: lukasz.langa, pitrou priority: normal severity: normal status: open title: weakref spewing exceptions during finalization when combined with multiprocessing type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 02:29:46 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Fri, 10 Feb 2017 07:29:46 +0000 Subject: [New-bugs-announce] [issue29520] Documentation uses deprecated "defindex.html" Sphinx template Message-ID: <1486711786.11.0.823688079421.issue29520@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: When I build the documentation on the current CPython code, there is a deprecation warning on the console. ===== (beginning of output) % make html sphinx-build -b html -d build/doctrees -D latex_elements.papersize= . build/html Running Sphinx v1.5.2 ...[omitted irrelevant output]... generating indices... genindex py-modindex writing additional pages... download index WARNING: Now base template defindex.html is deprecated. search opensearch copying images... [100%] faq/python-video-icon.png ...[omitted irrelevant output]... build succeeded, 1 warning. Build finished. The HTML pages are in build/html. ===== (end of output) This is observed when building documentation from branch master, commit b1dc6b6d5fa20f63f9651df2e7986a066c88ff7d . The build command is "cd Doc; make html". There are other warnings in the output, and I'm dealing with them in a different issue (number to follow). They are easier to fix than this one. Diagnosis: Sphinx config file Doc/conf.py:72 invokes the building of template 'indexcontent.html'. Doc/tools/templates/indexcontent.html:1 contains Sphinx directive `{% extends "defindex.html" %}`. This invokes file sphinx/sphinx/themes/basic/defindex.html [See https://github.com/sphinx-doc/sphinx/blob/8ecd7ff08249739bbc6d900527fe9306592456ab/sphinx/themes/basic/defindex.html ]. Sure enough, it issues a deprecation warning. {{ warn('Now base template defindex.html is deprecated.') }} There's a story behind this file. Sphinx issue 2986 (https://github.com/sphinx-doc/sphinx/issues/2986) says that this is a very old file, from about the 0.2 version of Sphinx. It wasn't HTML 5 compatible, so they declared it obsolete and threw it out. Well, that lasted only about two weeks. It became apparent that not only Python's docs, but thousands of other projects, seem to rely on it. So, defindex.html was restored, but with the deprecation warning. Then, on 1. January 2017, Sphinx deleted defindex.html again. (See https://github.com/sphinx-doc/sphinx/commit/45d3f2e8b279efa9d42068d4109cd97eb3f2d899 ). I can only imagine that, once this change makes it into the public release of Sphinx, Python's documentation, and that of thousands of projects, will break again. So, it seems like a good idea to proactively remove the dependence on this Sphinx file, before that new Sphinx release comes out. Options: 1. Copy the Sphinx defindex.html file into our source tree, and keep using it. Plus points: it's simple and easy. Minus points: the Sphinx licence terms may not permit this. And, it is not HTML5 compatible, which we might care about. 2. Identify the template which Sphinx intends as a successor to defindex.html, and switch to using that. I've done a bit of searching, and couldn't find out which template that might be. 3. Reimplement our Doc/tools/templates/indexcontent.html to rely on supported Sphinx template, and replace whatever intermediate content we were using from defindex.html with freshly-written code. I don't have a solution in mind for this issue. I just want to get it in the bug list, so we know about it. ---------- assignee: docs at python components: Documentation messages: 287478 nosy: JDLH, docs at python priority: normal severity: normal status: open title: Documentation uses deprecated "defindex.html" Sphinx template type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 03:14:19 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Fri, 10 Feb 2017 08:14:19 +0000 Subject: [New-bugs-announce] [issue29521] Minor warning messages when compiling documentation Message-ID: <1486714459.11.0.428886237265.issue29521@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: When I build the documentation on the current CPython code, there are various error and warning messages on the console. Here's what my build output looks like. I've marked the messages I'm concerned about with a numbered >>0>> prefix. ===== (beginning of output) % make html sphinx-build -b html -d build/doctrees -D latex_paper_size= . build/html Running Sphinx v1.5.2 loading pickled environment... done >>1>> WARNING: latex_preamble is deprecated. Use latex_elements['preamble'] instead. >>2>> WARNING: latex_paper_size is deprecated. Use latex_elements['papersize'] instead. building [mo]: targets for 0 po files that are out of date building [html]: targets for 466 source files that are out of date updating environment: 0 added, 1 changed, 0 removed reading sources... [100%] whatsnew/changelog >>3>> ../../Misc/NEWS:659: WARNING: Inline emphasis start-string without end-string. >>4>> ../../Misc/NEWS:659: WARNING: Inline emphasis start-string without end-string. looking for now-outdated files... none found pickling environment... done checking consistency... done preparing documents... done writing output... [100%] whatsnew/index >>5>> /Users/jdlh/workspace/cpython_github/Doc/faq/windows.rst:303: WARNING: unknown option: -t generating indices... genindex py-modindex writing additional pages... download index >>6>> WARNING: Now base template defindex.html is deprecated. search opensearch copying images... [100%] using/win_installer.png copying static files... done copying extra files... done dumping search index in English (code: en) ... done dumping object inventory... done build succeeded, 6 warnings. Build finished. The HTML pages are in build/html. ===== (end of output) This is observed when building documentation from branch master, commit b1dc6b6d5fa20f63f9651df2e7986a066c88ff7d . The build command is "cd Doc; make html". Warning >>6>> is the subject of http://bugs.python.org/issue29520 . It's harder to fix, and I won't address it here. The other five warnings are pretty easy to fix. Warnings >>1>>, >>2>> are Sphinx warnings about names used in Doc/conf.py , namely `latex_preamble` and `latex_paper_size`. There are straightforward changes to build a dict latex_elements{}, with keys 'preamble' and 'papersize'. It turns out that makefiles Doc/Makefile and Doc/make.bat also referred to `latex_paper_size`. Those references are rewritten as `latex_elements.papersize`, per Sphinx syntax for external names. Warnings >>3>>, >>4>> are Sphinx warnings about the text, in Misc/NEWS:661, ```is now of type "const char *" rather of "char *".``` Put a backslash in front of the '*', and the warning disappears. Warning >>5>> is a Sphinx warning about this text, in Doc/faq/windows.rst:303: If you suspect mixed tabs and spaces are causing problems in leading whitespace, run Python with the :option:`-t` switch or run ``Tools/Scripts/tabnanny.py`` to check a directory tree in batch mode. The notation :option:`-t` seems to need a corresponding ``.. cmdoption:: -t `` entry, perhaps in the same file. There is no such entry. It turns out that the -t option has no function in Python 3.6, maybe in all of 3.x. Python swallows the option but does nothing. Thus, instead of trying to make the reference to '-t' work, I decided to cut the whole phrase. This paragraph now reads, If you suspect mixed tabs and spaces are causing problems in leading whitespace, run ``Tools/Scripts/tabnanny.py`` to check a directory tree in batch mode. I am making a Pull Request with these fixes. I will shortly link to it from here. ---------- assignee: docs at python components: Documentation messages: 287480 nosy: JDLH, docs at python priority: normal severity: normal status: open title: Minor warning messages when compiling documentation type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 03:55:23 2017 From: report at bugs.python.org (nico) Date: Fri, 10 Feb 2017 08:55:23 +0000 Subject: [New-bugs-announce] [issue29522] PyLong_AsDouble Behaviour is Weird Message-ID: <1486716923.02.0.912981013362.issue29522@psf.upfronthosting.co.za> New submission from nico: I'm using the pre-installed version of Python 2.7.12 on Ubuntu 16.04. Pretty straight forward error the following code: PyObject * intobj = PyInt_FromLong(10); double d1 = (double)PyLong_AsLong(intobj); double d2 = PyLong_AsDouble(intobj); printf("Should be the same: %f vs %f", d1, d2); Does not display the same number for both double since `PyLong_AsDouble` raises the error, SystemError: ../Objects/longobject.c:2336: bad argument to internal function and returns -1.0 instead of 10.0. ---------- components: Build messages: 287486 nosy: nico priority: normal severity: normal status: open title: PyLong_AsDouble Behaviour is Weird versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 05:14:21 2017 From: report at bugs.python.org (Charalampos Stratakis) Date: Fri, 10 Feb 2017 10:14:21 +0000 Subject: [New-bugs-announce] [issue29523] latest setuptools breaks virtualenvs due to unbundling dependencies Message-ID: <1486721661.65.0.755330059103.issue29523@psf.upfronthosting.co.za> New submission from Charalampos Stratakis: The latest versions of setuptools stopped bundling its dependencies and instead starting requiring them [0]. This seems to break virtualenvs as those dependencies are not bundled with python. In order to reproduce it, replace the setuptools-28.8.0-py2.py3-none-any.whl with setuptools-34.1.1-py2.py3-none-any.whl at Lib/ensurepip/_bundled/ and change _SETUPTOOLS_VERSION = "28.8.0" to _SETUPTOOLS_VERSION = "34.1.1" Then configure, make and make install: This message will appear first: Could not find a version that satisfies the requirement packaging>=16.8 (from setuptools) (from versions: ) No matching distribution found for packaging>=16.8 (from setuptools) Which is one of the new dependencies. Then: ./python3.7 -m test test_venv -v Where the EnsurePipTest will fail due to this assertion [1] at the do_test_with_pip test case with "No module named pip\n' != ''". One way to fix this would be to bundle the other wheels with python, not sure if that would be the ideal approach though. Attaching a patch for Lib/ensurepip/__init__.py. With this patch and adding the other wheels [2][3][4][5] at the _bundled directory fixes the issue. [0] https://github.com/pypa/setuptools/blob/master/CHANGES.rst#v3400 [1] https://github.com/python/cpython/blob/master/Lib/test/test_venv.py#L384 [2] https://pypi.python.org/pypi/six/1.10.0 [3] https://pypi.python.org/pypi/appdirs/1.4.0 [4] https://pypi.python.org/pypi/packaging/16.8 [5] https://pypi.python.org/pypi/pyparsing/2.1.10 ---------- components: Distutils, Library (Lib) files: bundle-setuptools-dependencies.patch keywords: patch messages: 287504 nosy: cstratak, dstufft, eric.araujo priority: normal severity: normal status: open title: latest setuptools breaks virtualenvs due to unbundling dependencies versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46621/bundle-setuptools-dependencies.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 07:42:39 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 12:42:39 +0000 Subject: [New-bugs-announce] [issue29524] Move functions to call objects into a new Objects/call.c file Message-ID: <1486730559.24.0.70996002415.issue29524@psf.upfronthosting.co.za> New submission from STINNER Victor: I propose to move functions to call objects into a new Objects/call.c file. It should easy maintainance since all moved functions are inter-dependent: it becomes easier to keep them consistent since they are in the same fle. I also have a small "hope" that moving "call" functions in the same file should help the compiler to produce more efficient code and that we will get a better "code placement". Closer functions should enhance the usage of the CPU instruction cache. I don't know exactly how to measure the effect of code placement. My plan is to push the change, and then watch speed.python.org timeline. Attached call.patch: * Add Objects/call.c file * Move all functions to call objects in a new Objects/call.c file. * Rename fast_function() to _PyFunction_FastCallKeywords(). * Copy null_error() from Objects/abstract.c * Inline type_error() in call.c to not have to copy it, it was only called once. * Export _PyEval_EvalCodeWithName() since it is now called from call.c. The change comes from the issue #29465. Copy of my msg287257 from this issue: --- Serhiy Storchaka added the comment: > Isn't the Python directory more appropriate place for call.c? I moved code from other .c files in Objects/, so for me it seems more natural to add the code in Objects/ as well. It seems like most of the code in Python/ is not "aware" of types defined in Objects/. But I don't have a strong opinion on the right directory. Objects/call.c is 1500 lines long. IMHO the code became big enough to justify to move it to a new file ;-) --- Once we have a call.c file, we may try other changes to enhance the code placement: * Add "#define PY_LOCAL_AGGRESSIVE" (only used by Visual Studio) * Tag functions with _Py_HOT_FUNCTION: see the issue #28618 for discussion on __attribute__((hot)). The last time I checked, it wasn't enough to fix all "code placement issues". * Reorder functions in call.c: I dislike this idea, IMHO it's too hard to guess ourself what is the best order, and it's likely to produce many commits for little benefit See also the issue #29465: "Add _PyObject_FastCall() to reduce stack consumption. ---------- components: Interpreter Core files: call.patch keywords: patch messages: 287527 nosy: haypo, inada.naoki, serhiy.storchaka priority: normal severity: normal status: open title: Move functions to call objects into a new Objects/call.c file versions: Python 3.7 Added file: http://bugs.python.org/file46624/call.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 08:28:11 2017 From: report at bugs.python.org (Frak N) Date: Fri, 10 Feb 2017 13:28:11 +0000 Subject: [New-bugs-announce] [issue29525] Python 2.7.13 for Windows broken (from prompt) Message-ID: <1486733291.65.0.0897446946513.issue29525@psf.upfronthosting.co.za> New submission from Frak N: I used to have an older version of python 2.7 that has worked for years. I just upgraded to 2.7.13 for Windows, 32 bit and now, I can't get the interpreter to run from the command line. It just returns to the DOS prompt. c:\Python27>python Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. c:\Python27>python PC: OS: Windows 7 - 64 bit (I am intentionally using the 32bit of python) Processor: AMD PhenomII 975 Processor. 3.6GHz RAM: 16GB ---------- components: Windows messages: 287532 nosy: Frak N, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python 2.7.13 for Windows broken (from prompt) type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 09:13:56 2017 From: report at bugs.python.org (Hugo Prod'homme) Date: Fri, 10 Feb 2017 14:13:56 +0000 Subject: [New-bugs-announce] [issue29526] Documenting format() function Message-ID: <1486736036.14.0.349493431315.issue29526@psf.upfronthosting.co.za> New submission from Hugo Prod'homme: Hello python contributors, this is my first time on python.org and I am coming with a suggestion. The idea is to help people that have to format strings containing numbers of various kinds, I am from the scientific domain but this should help everybody anyway. In the past the strftime was the best way to format numbers in strings (truncating to some digits after point, setting to exponent notation, etc...). To remind the "strf language" one had to use the internet or a document such as this page : http://strftime.org/ Some idea was provided to add this indications in the python docs. http://bugs.python.org/issue9650 Now the format() function has appeared in the python __builtins__ and this is even more adequate to add help about the string formatting, because we can write the "Format Specification Mini-Language" directly inside the docstring of the format.__doc__ . See the paragraph named "7.1.3.1. Format Specification Mini-Language" in the following page : https://docs.python.org/2/library/string.html I emphasize, the interest of this is to allow the user to be reminded of the formatting options without opening another document than his(her) script, to avoid breaking the workflow. I am providing what I think is the minimal material that the docstring should contains within the attached file. I am not really familiar with docstring formatting according to PEP (436?) and someone should help getting this in the right way of writing. Furthermore, a specific syntax is needed within the string in addition to the format() arguments, this should be described. And the reminder about the mini-language should appear clearly as a reminder. These are two supplemental difficulties in comparison with an usual docstring. To anyone thinking something else should be added to the docstring; please add or say it. PS: I think I can start from the matplotlib.pyplot.plot.__doc__ as a template to complete the format.__doc__ but I have some work aside for now. ---------- files: format_docstring_v0.1.txt messages: 287539 nosy: hugo.prodhomme at gmx.fr priority: normal severity: normal status: open title: Documenting format() function type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46625/format_docstring_v0.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 18:49:33 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Feb 2017 23:49:33 +0000 Subject: [New-bugs-announce] [issue29527] Travis: doc job is broken Message-ID: <1486770573.93.0.256816932878.issue29527@psf.upfronthosting.co.za> New submission from STINNER Victor: I suggest to disable the job until it's fixed, just to fix Travis right now. This issue will track the bug to find a solution. https://travis-ci.org/python/cpython/jobs/200517775 $ make html SPHINXBUILD="./venv/bin/python3 -m sphinx" SPHINXOPTS="-nW -q -b linkcheck" ./venv/bin/python3 -m sphinx -b html -d build/doctrees -D latex_paper_size= -nW -q -b linkcheck . build/html Warning, treated as error: WARNING: latex_preamble is deprecated. Use latex_elements['preamble'] instead. make: *** [build] Error 1 ---------- components: Tests messages: 287573 nosy: haypo priority: normal severity: normal status: open title: Travis: doc job is broken versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 18:58:09 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Feb 2017 23:58:09 +0000 Subject: [New-bugs-announce] [issue29528] Encrypt IRC channel details Message-ID: <1486771089.77.0.265289321985.issue29528@psf.upfronthosting.co.za> New submission from Brett Cannon: Donald pointed out on IRC we should encrypt a channel key for IRC so that it doesn't get flooded from people's forks. See https://docs.travis-ci.com/user/notifications#Channel-key for documentation on how to do this. ---------- messages: 287575 nosy: brett.cannon, dstufft, r.david.murray priority: high severity: normal status: open title: Encrypt IRC channel details _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 18:59:00 2017 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Feb 2017 23:59:00 +0000 Subject: [New-bugs-announce] [issue29529] Backport Travis configuration Message-ID: <1486771140.47.0.770899146188.issue29529@psf.upfronthosting.co.za> New submission from Brett Cannon: Once the Travis config stabilizes then it should be backported to all active branches. ---------- assignee: brett.cannon messages: 287576 nosy: brett.cannon priority: normal severity: normal status: open title: Backport Travis configuration versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 20:58:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Sat, 11 Feb 2017 01:58:36 +0000 Subject: [New-bugs-announce] [issue29530] Windows buildbots broken by the migration to GitHub (meta issue) Message-ID: <1486778316.24.0.828408222138.issue29530@psf.upfronthosting.co.za> New submission from STINNER Victor: (*) I noticed test_sax and test_random failures on Windows since CPython moved to GitHub. These failures seem to be caused by newlines: see issue #27425. (*) "AMD64 Windows7 SP1 3.x" fails on the "git" step with: 'git' is not recognized as an internal or external command I contacted the slave owner, Jeremy, to ask him to install git. ---------- components: Tests keywords: buildbot messages: 287587 nosy: haypo priority: normal severity: normal status: open title: Windows buildbots broken by the migration to GitHub (meta issue) versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 10 22:15:55 2017 From: report at bugs.python.org (Roger Sachan) Date: Sat, 11 Feb 2017 03:15:55 +0000 Subject: [New-bugs-announce] [issue29531] Update Doc/README.txt to README.rst Message-ID: <1486782955.84.0.790445340079.issue29531@psf.upfronthosting.co.za> New submission from Roger Sachan: I have simply updated the document and its references to README.rst (thanks to whoever formatted it). ---------- assignee: docs at python components: Documentation messages: 287590 nosy: Roger Sachan, docs at python priority: normal pull_requests: 29 severity: normal status: open title: Update Doc/README.txt to README.rst type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 02:20:01 2017 From: report at bugs.python.org (Naoyuki Kamo) Date: Sat, 11 Feb 2017 07:20:01 +0000 Subject: [New-bugs-announce] [issue29532] functools.partial is not compatible between 2.7 and 3.5 Message-ID: <1486797601.63.0.771798059735.issue29532@psf.upfronthosting.co.za> New submission from Naoyuki Kamo: The code: from functools import partial def f(a): print(a) d = {'a': 3} g = partial(f, **d) g() d['a'] = 5 g() On python2.7, gets 3 but on python3.5, gets 5 is it a bug? ---------- messages: 287594 nosy: naoyuki priority: normal severity: normal status: open title: functools.partial is not compatible between 2.7 and 3.5 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 03:43:27 2017 From: report at bugs.python.org (Julia Dolgova) Date: Sat, 11 Feb 2017 08:43:27 +0000 Subject: [New-bugs-announce] [issue29533] urllib2 works slowly with proxy on windows Message-ID: <1486802607.23.0.387912582288.issue29533@psf.upfronthosting.co.za> New submission from Julia Dolgova: I've found that urllib works sometimes slowly on windows with proxy. To reproduce the issue: on Windows: 1. Turn on the option "use proxy" in "browser settings" in "control panel". No real proxy needed. The problem will come out before addressing to proxy. Just don't pay attention to exception. 2. Make sure that the list of addresses for proxy bypass is not empty 3. Execute checklib.py with socket.py (attached here) in the same directory The result output could be: A (not a problem): Before call to _socket.gethostbyaddr("docs.python.org") After call to _socket.gethostbyaddr("docs.python.org") B (little problem): Before call to _socket.gethostbyaddr("docs.python.org") Exception in call to _socket.gethostbyaddr("docs.python.org") C (worse problem): Before call to _socket.gethostbyaddr("docs.python.org") (Delay) Exception in call to _socket.gethostbyaddr("docs.python.org") The result A,B or C depends on what DNS server you use, what url you pass into urllib2.urlopen(), and could differ at different time because dns is not a stable thing. However, no matter what result you have, this test shows that a hostname is passed into gethostbyaddr instead of IP as expected and described in MSDN. It should be changed to gethostbyname_ex here. test.py compare performance of gethostbyaddr and gethostbyname_ex. It sets different dns servers on the system and calls these functions with different hostnames passed into. Run on my computer shows that gethostbyname_ex is 3 times more productive and doesn't raise exceptions. ----------------------------- Attached files: checklib.py - just make a call to urllib2.urlopen("https://docs.python.org") socket.py - not a patched lib. Has debug lines near 141 line. Use it with checklib.py. test.py - compare performance of gethostbyaddr with gethostbyname_ex log.txt - result of test.py on my computer (Windows 8, 64 bit) socket.patch - socket.py patch ---------- components: Library (Lib), Windows files: checklib.py messages: 287597 nosy: juliadolgova, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: urllib2 works slowly with proxy on windows type: performance versions: Python 2.7 Added file: http://bugs.python.org/file46628/checklib.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 08:54:15 2017 From: report at bugs.python.org (Armin Rigo) Date: Sat, 11 Feb 2017 13:54:15 +0000 Subject: [New-bugs-announce] [issue29534] _decimal difference with _pydecimal Message-ID: <1486821255.04.0.156424545638.issue29534@psf.upfronthosting.co.za> New submission from Armin Rigo: A difference in behavior between _decimal and _pydecimal (it seems that _decimal is more consistent in this case): class X(Decimal): def __init__(self, a): print('__init__:', a) X.from_float(42.5) # __init__: Decimal('42.5') X.from_float(42) # with _pydecimal: __init__: 42 # with _decimal: __init__: Decimal('42') ---------- messages: 287600 nosy: arigo priority: normal severity: normal status: open title: _decimal difference with _pydecimal type: behavior versions: Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 10:16:53 2017 From: report at bugs.python.org (Armin Rigo) Date: Sat, 11 Feb 2017 15:16:53 +0000 Subject: [New-bugs-announce] [issue29535] datetime hash is deterministic in some cases Message-ID: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> New submission from Armin Rigo: The documentation on the hash randomization says that date, time and datetime have a hash based on strings, that is therefore nondeterministic in several runs of Python. I may either be missing a caveat, or the actual implementation does not follow its promise in case a timezone is attached to the datetime or time object: ~/svn/python/3.7-debug/python -c "import datetime;print(hash(d atetime.datetime(2016,10,10,0,0,0,0,datetime.timezone(datetime.timedelta(0, 36000)))))" (this gives -6021186165085109055 all the time) ~/svn/python/3.7-debug/python -c "import datetime;print(hash(datetime.time(0,0,0,0, datetime.timezone(datetime.timedelta(0, 36000)))))" (this gives -3850122659820237607 all the time) ---------- messages: 287601 nosy: arigo priority: normal severity: normal status: open title: datetime hash is deterministic in some cases type: security versions: Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 11 16:27:48 2017 From: report at bugs.python.org (Sachin Kumar) Date: Sat, 11 Feb 2017 21:27:48 +0000 Subject: [New-bugs-announce] [issue29536] test_hashlib failure on Ubuntu 16.04 Message-ID: <1486848468.11.0.403727240119.issue29536@psf.upfronthosting.co.za> New submission from Sachin Kumar: When executing ./python -m test -v test_hashlib on Python 3.7, the test fails. This is the complete traceback: CPython 3.7.0a0 (default, Feb 8 2017, 03:10:42) [GCC 5.4.0 20160609] == Linux-4.4.0-62-generic-x86_64-with-debian-stretch-sid little-endian == hash algorithm: siphash24 64bit == cwd: /XXX/build/test_python_14437 == encodings: locale=UTF-8, FS=utf-8 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) Run tests sequentially 0:00:00 [1/1] test_hashlib test_algorithms_available (test.test_hashlib.HashLibTestCase) ... ok test_algorithms_guaranteed (test.test_hashlib.HashLibTestCase) ... ok test_blake2b (test.test_hashlib.HashLibTestCase) ... ok test_blake2b_vectors (test.test_hashlib.HashLibTestCase) ... ERROR test_blake2s (test.test_hashlib.HashLibTestCase) ... ok test_blake2s_vectors (test.test_hashlib.HashLibTestCase) ... ERROR test_blocksize_name (test.test_hashlib.HashLibTestCase) ... ok test_blocksize_name_blake2 (test.test_hashlib.HashLibTestCase) ... ok test_blocksize_name_sha3 (test.test_hashlib.HashLibTestCase) ... ok test_case_blake2b_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_blake2b_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_blake2s_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_blake2s_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_md5_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_md5_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_md5_2 (test.test_hashlib.HashLibTestCase) ... ok test_case_md5_huge (test.test_hashlib.HashLibTestCase) ... skipped 'not enough memory: 4.0G minimum needed' test_case_md5_uintmax (test.test_hashlib.HashLibTestCase) ... skipped 'not enough memory: 4.0G minimum needed' test_case_sha1_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha1_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha1_2 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha1_3 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha224_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha224_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha224_2 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha224_3 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha256_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha256_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha256_2 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha256_3 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha384_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha384_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha384_2 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha384_3 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha3_224_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha3_224_vector (test.test_hashlib.HashLibTestCase) ... ERROR test_case_sha3_256_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha3_256_vector (test.test_hashlib.HashLibTestCase) ... ERROR test_case_sha3_384_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha3_384_vector (test.test_hashlib.HashLibTestCase) ... ERROR test_case_sha3_512_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha3_512_vector (test.test_hashlib.HashLibTestCase) ... ERROR test_case_sha512_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha512_1 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha512_2 (test.test_hashlib.HashLibTestCase) ... ok test_case_sha512_3 (test.test_hashlib.HashLibTestCase) ... ok test_case_shake128_vector (test.test_hashlib.HashLibTestCase) ... ERROR test_case_shake256_vector (test.test_hashlib.HashLibTestCase) ... ERROR test_case_shake_128_0 (test.test_hashlib.HashLibTestCase) ... ok test_case_shake_256_0 (test.test_hashlib.HashLibTestCase) ... ok test_extra_sha3 (test.test_hashlib.HashLibTestCase) ... ok test_get_builtin_constructor (test.test_hashlib.HashLibTestCase) ... ok test_gil (test.test_hashlib.HashLibTestCase) ... ok test_hash_array (test.test_hashlib.HashLibTestCase) ... ok test_hexdigest (test.test_hashlib.HashLibTestCase) ... ok test_large_update (test.test_hashlib.HashLibTestCase) ... ok test_name_attribute (test.test_hashlib.HashLibTestCase) ... ok test_no_unicode (test.test_hashlib.HashLibTestCase) ... ok test_no_unicode_blake2 (test.test_hashlib.HashLibTestCase) ... ok test_no_unicode_sha3 (test.test_hashlib.HashLibTestCase) ... ok test_threaded_hashing (test.test_hashlib.HashLibTestCase) ... ok test_unknown_hash (test.test_hashlib.HashLibTestCase) ... ok test_pbkdf2_hmac_c (test.test_hashlib.KDFTests) ... ok test_pbkdf2_hmac_py (test.test_hashlib.KDFTests) ... ok test_scrypt (test.test_hashlib.KDFTests) ... skipped ' test requires OpenSSL > 1.1' ====================================================================== ERROR: test_blake2b_vectors (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 623, in test_blake2b_vectors for msg, key, md in read_vectors('blake2b'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_blake2s_vectors (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 648, in test_blake2s_vectors for msg, key, md in read_vectors('blake2s'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_case_sha3_224_vector (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 659, in test_case_sha3_224_vector for msg, md in read_vectors('sha3_224'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_case_sha3_256_vector (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 669, in test_case_sha3_256_vector for msg, md in read_vectors('sha3_256'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_case_sha3_384_vector (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 680, in test_case_sha3_384_vector for msg, md in read_vectors('sha3_384'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_case_sha3_512_vector (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 691, in test_case_sha3_512_vector for msg, md in read_vectors('sha3_512'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_case_shake128_vector (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 703, in test_case_shake128_vector for msg, md in read_vectors('shake_128'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ====================================================================== ERROR: test_case_shake256_vector (test.test_hashlib.HashLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hashlib.py", line 715, in test_case_shake256_vector for msg, md in read_vectors('shake_256'): File "/XXX/Lib/test/test_hashlib.py", line 69, in read_vectors parts[0] = bytes.fromhex(parts[0]) ValueError: non-hexadecimal number found in fromhex() arg at position 0 ---------------------------------------------------------------------- Ran 65 tests in 0.877s FAILED (errors=8, skipped=3) test test_hashlib failed test_hashlib failed 1 test failed: test_hashlib Total duration: 1 sec Tests result: FAILURE ---------- components: Tests messages: 287626 nosy: Sachin Kumar priority: normal severity: normal status: open title: test_hashlib failure on Ubuntu 16.04 type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 09:28:54 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Feb 2017 14:28:54 +0000 Subject: [New-bugs-announce] [issue29537] Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 Message-ID: <1486909734.86.0.721049479861.issue29537@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch is an alternative fix of issue27286 for Python 3.5. Rather than fixing the compiler and bumping the magic number it just avoids using incorrect value in eval loop. The patch can be useful for disro maintainers that don't want to recompile all .pyc files when update Python to 3.5.3. I think it would be the best way to fix issue27286. Now it can be combined with either reverting issue27286 changes or applying the workaround https://github.com/encukou/cpython/commit/magic-number-workaround . The patch makes the high byte of oparg be used only when it is unambiguous (equal to 1). In that case the error message contains a function name. Otherwise the error message doesn't contain a function name. This is small usability regression, but the BUILD_MAP_UNPACK_WITH_CALL opcode is very rarely used and shouldn't raise an exception in normal case. ---------- components: Interpreter Core messages: 287637 nosy: barry, encukou, ncoghlan, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Alternative fix for BUILD_MAP_UNPACK_WITH_CALL opcode in 3.5 versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 18:43:58 2017 From: report at bugs.python.org (Paul Schreiber) Date: Sun, 12 Feb 2017 23:43:58 +0000 Subject: [New-bugs-announce] [issue29538] bugs.python.org does not redirect to HTTPS Message-ID: <1486943038.63.0.542999854089.issue29538@psf.upfronthosting.co.za> New submission from Paul Schreiber: bugs.python.org does not redirect HTTP requests to HTTPS and does not provide Strict Transport Security. ---------- messages: 287661 nosy: paulschreiber priority: normal severity: normal status: open title: bugs.python.org does not redirect to HTTPS type: security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 19:45:25 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Mon, 13 Feb 2017 00:45:25 +0000 Subject: [New-bugs-announce] [issue29539] [smtplib] collect response data for all recipients Message-ID: <1486946725.6.0.180199923995.issue29539@psf.upfronthosting.co.za> New submission from David Ford (FirefighterBlu3): Feature request; collect SMTP response results for all recipients so data likely including the queue ID or SMTP delay expectation can be collected I propose the keyword "keep_results=False" be added to smtplib.sendmail() to accomplish this. The default value of False maintains the legacy functionality of prior versions. No other changes have been done to smtplib.send_message() pending discussion of the following. @@ -785,7 +785,7 @@ return (resp, reply) def sendmail(self, from_addr, to_addrs, msg, mail_options=[], - rcpt_options=[]): + rcpt_options=[], keep_results=False): """This command performs an entire mail transaction. The arguments are: @@ -797,6 +797,8 @@ mail command. - rcpt_options : List of ESMTP options (such as DSN commands) for all the rcpt commands. + - keep_results : If True, return a dictionary of recipients and the + SMTP result for each. msg may be a string containing characters in the ASCII range, or a byte string. A string is encoded to bytes using the ascii codec, and lone @@ -807,17 +809,20 @@ and each of the specified options will be passed to it. If EHLO fails, HELO will be tried and ESMTP options suppressed. - This method will return normally if the mail is accepted for at least - one recipient. It returns a dictionary, with one entry for each - recipient that was refused. Each entry contains a tuple of the SMTP - error code and the accompanying error message sent by the server. + If keep_results is False, this method will return normally if the mail + is accepted for at least one recipient. It returns a dictionary, with + one entry for each recipient that was refused. Each entry contains a + tuple of the SMTP error code and the accompanying error message sent by + the server. If keep_results is True, this method returns a dictionary + of all recipients and the SMTP result whether refused or accepted + unless all are refused then the normal exception is raised. This method may raise the following exceptions: SMTPHeloError The server didn't reply properly to the helo greeting. - SMTPRecipientsRefused The server rejected ALL recipients - (no mail was sent). + SMTPRecipientsRefused The server rejected ALL recipients (no mail + was sent). SMTPSenderRefused The server didn't accept the from_addr. SMTPDataError The server replied with an unexpected error code (other than a refusal of @@ -879,6 +884,10 @@ self._rset() raise SMTPRecipientsRefused(senderrs) (code, resp) = self.data(msg) + if keep_results: + for each in to_addrs: + if not each in senderrs: + senderrs[each]=(code, resp) if code != 250: if code == 421: self.close() ---------- components: email messages: 287662 nosy: David Ford (FirefighterBlu3), barry, r.david.murray priority: normal severity: normal status: open title: [smtplib] collect response data for all recipients type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 12 21:04:34 2017 From: report at bugs.python.org (Alex Gordon) Date: Mon, 13 Feb 2017 02:04:34 +0000 Subject: [New-bugs-announce] [issue29540] Add compact=True flag to json.dump/dumps Message-ID: <1486951474.88.0.917635653579.issue29540@psf.upfronthosting.co.za> New submission from Alex Gordon: Broadly speaking, there are three main output styles for json.dump/dumps: 1. Default: json.dumps(obj) 2. Compact: json.dumps(obj, separators=(',', ':')) 3. Pretty-printing: json.dumps(obj, sort_keys=True, indent=4) The 'compact' style is the densest, suitable if the JSON is to be sent over the network, archived on disk, or otherwise consumed by a machine. The pretty-printed style is for human consumption: configuration files, debugging, etc. Even though the compact style is often desirable, the API for producing it is unforgiving. It's easy to accidentally write code like the following, which silently produces invalid nonsense: json.dumps(obj, separators=(':', ',')) I propose the addition of a new flag `compact=True`, that simply sets `separators=(',', ':')`. e.g. >>> obj = {"foo": 1, "bar": 2} >>> json.dumps(obj, compact=True) '{"foo":1,"bar":2}' The defaults for `separators=` are good, so eventually `compact=` would relegate `separators=` to obscurity. Setting both `compact=True` and `separators=` at the same time should be an error. ---------- components: Library (Lib) messages: 287663 nosy: Alex Gordon priority: normal severity: normal status: open title: Add compact=True flag to json.dump/dumps type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 02:52:21 2017 From: report at bugs.python.org (=?utf-8?q?Honza_Sk=C3=BDpala?=) Date: Mon, 13 Feb 2017 07:52:21 +0000 Subject: [New-bugs-announce] [issue29541] Python3 error while building on Alt-F Message-ID: <1486972341.9.0.0995375126995.issue29541@psf.upfronthosting.co.za> New submission from Honza Sk?pala: While trying to build Python 3.6.0 on emmbedded Linux device ? D-Link DNS-320L running Alt-F firmware (Linux 3.18.28 #1 Fri Jun 17 14:44:39 WEST 2016 armv5tel GNU/Linux), it fails with ./python: can't resolve symbol 'crypt' make: *** [sharedmods] Error 1 I can see the python executable is compiled fine in the source directory, if I try to run it, then it does work, including some quick tests (calculations, os.getcwd, random.randint -- works fine). I can also see that compiling the crypt modules did not report any errors and the .o file is present on the disk. I guess it is some kind of linking error? Attaching the log from the build. ---------- components: Build files: build.log messages: 287666 nosy: Honza Sk?pala priority: normal severity: normal status: open title: Python3 error while building on Alt-F type: compile error versions: Python 3.6 Added file: http://bugs.python.org/file46636/build.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 05:35:03 2017 From: report at bugs.python.org (Vladimir Shebunyaev) Date: Mon, 13 Feb 2017 10:35:03 +0000 Subject: [New-bugs-announce] [issue29542] python -m spacy.en.download undefined symbol: _ZSt24__throw_out_of_range_fmtPKcz Message-ID: <1486982103.81.0.103428043844.issue29542@psf.upfronthosting.co.za> New submission from Vladimir Shebunyaev: I have (python 2.7.13 Anaconda 4.3.0 64bit Ubuntu 16 ) tried python -m spacy.en.download and got /home/vshebuniayeu/anaconda2/bin/python: /home/vshebuniayeu/anaconda2/lib/python2.7/site-packages/spacy/serialize/huffman.so: undefined symbol: _ZSt24__throw_out_of_range_fmtPKcz ---------- messages: 287674 nosy: Vladimir Shebunyaev priority: normal severity: normal status: open title: python -m spacy.en.download undefined symbol: _ZSt24__throw_out_of_range_fmtPKcz type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 10:02:37 2017 From: report at bugs.python.org (Paul Schreiber) Date: Mon, 13 Feb 2017 15:02:37 +0000 Subject: [New-bugs-announce] [issue29543] Allow login to bugs.python.org with email address Message-ID: <1486998157.34.0.838139169099.issue29543@psf.upfronthosting.co.za> New submission from Paul Schreiber: Allow users to log in to bugs.python.org with the email address in the username field. ---------- messages: 287699 nosy: paulschreiber priority: normal severity: normal status: open title: Allow login to bugs.python.org with email address type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 10:07:47 2017 From: report at bugs.python.org (Paul Schreiber) Date: Mon, 13 Feb 2017 15:07:47 +0000 Subject: [New-bugs-announce] [issue29544] Allow login to bugs.python.org with Google account Message-ID: <1486998467.47.0.572774798613.issue29544@psf.upfronthosting.co.za> New submission from Paul Schreiber: I created a standard account on bugs.python.org with username paulschreiber and email address paulschreiber at gmail.com. Later, I attempted to log in to bugs.python.org using Google and was shown an error message: There is already an account for paulschreiber at gmail.com Instead of showing me the error message, I should have been logged in. ---------- messages: 287701 nosy: paulschreiber priority: normal severity: normal status: open title: Allow login to bugs.python.org with Google account type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 10:46:52 2017 From: report at bugs.python.org (Gireesh) Date: Mon, 13 Feb 2017 15:46:52 +0000 Subject: [New-bugs-announce] [issue29545] Python behavioral difference between Linux and AIX Message-ID: New submission from Gireesh: Here is my python code (parent): #!/usr/bin/env python import errno import os import pty from subprocess import Popen, STDOUT master_fd, slave_fd = pty.openpty() proc = Popen(['./a.out'],stdout=slave_fd, close_fds=True) os.close(slave_fd) data = os.read(master_fd, 512) print('got ' + repr(data)) Child(C++): #include #include #include int main() { printf("hello world\n"); exit(0); } behavior: Linux: got 'hello world\r\r\n' AIX: Hangs. versions: Linux: Linux 2.6.32-131.12.1.el6.x86_64 #1 SMP Sun Jul 31 16:44:56 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux AIX: 1 6 00F460A94C00 Python: 2.7.10 ---------- messages: 287706 nosy: gireeshpunathil priority: normal severity: normal status: open title: Python behavioral difference between Linux and AIX _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 11:30:11 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 Feb 2017 16:30:11 +0000 Subject: [New-bugs-announce] [issue29546] A more helpful ImportError message Message-ID: <1487003411.13.0.404377957211.issue29546@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: I haven't really thought about this deeply but I've observed that there are lots of cases where a user will report getting an ImportError trying to import a name from a module, where it turns out that the problem is that the module is coming from an unexpected location. Examples include pip installed packages overriding system packages, or unexpected vendorized wheels. The standard first response is typically, "can you please run this to tell us where the foo library is coming from?" E.g. ``` ^^ this is indicative of an old version of urllib3. Can you please double check whether you have an old urllib3 installed e.g. in /usr/local or ~/. Testing: $ python3 -c 'import urllib3; print(urllib3.__file__)' should return: /usr/lib/python3/dist-packages/urllib3/__init__.py and might tell you where else a locally installed urllib3 is to be found if it doesn't return that value. ``` It would be kind of useful if the original ImportError showed you where the module came from (i.e. its __file__), if such information can be discerned. E.g.: ``` >>> import requests; requests.__version__.split('.') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 61, in from .packages.urllib3.exceptions import DependencyWarning ImportError: cannot import name DependencyWarning from requests.packages.urllib3.exceptions (/usr/local/lib/python3.5/site-packages/requests/packages/urllib3.py) ``` If you saw that in a bug report, you'd almost immediately know that the user has some local override that's potentially causing the problem. ---------- components: Interpreter Core messages: 287708 nosy: barry priority: normal severity: normal status: open title: A more helpful ImportError message versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 11:54:51 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 13 Feb 2017 16:54:51 +0000 Subject: [New-bugs-announce] [issue29547] Add c code coverage to codecov Message-ID: <1487004891.23.0.966480827994.issue29547@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: I had it done in my fork of cpython-mirror: https://github.com/abalkin/cpython/tree/ci ---------- assignee: belopolsky components: Tests messages: 287710 nosy: belopolsky priority: normal severity: normal status: open title: Add c code coverage to codecov versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 12:36:52 2017 From: report at bugs.python.org (INADA Naoki) Date: Mon, 13 Feb 2017 17:36:52 +0000 Subject: [New-bugs-announce] [issue29548] deprecate PyEval_Call*() functions. Message-ID: <1487007412.2.0.380189857134.issue29548@psf.upfronthosting.co.za> New submission from INADA Naoki: As reading call.c, PyEval_Call* APIs are mostly duplicate of PyObject_Call* APIs. While they are not documented, they seems part of limited APIs. So we can't remove them easily. Let's deprecate them for now. ---------- components: Interpreter Core messages: 287714 nosy: inada.naoki priority: normal severity: normal status: open title: deprecate PyEval_Call*() functions. versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 15:57:22 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 13 Feb 2017 20:57:22 +0000 Subject: [New-bugs-announce] [issue29549] Improve docstring for str.index Message-ID: <1487019442.21.0.885918615749.issue29549@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The docstring for str.index() needs to be synced with the main documentation rather than presuming knowledge of str.find(). Currently it reads: >>> help(str.index) Help on method_descriptor: index(...) S.index(sub[, start[, end]]) -> int Like S.find() but raise ValueError when the substring is not found. And it should read more like str.find: help(str.find) Help on method_descriptor: find(...) S.find(sub[, start[, end]]) -> int Return the lowest index in S where substring sub is found, such that sub is contained within S[start:end]. Optional arguments start and end are interpreted as in slice notation. Return -1 on failure. Lisa, it would be great if you could draft-up a patch. ---------- assignee: lisroach components: Documentation messages: 287724 nosy: lisroach, rhettinger priority: normal severity: normal stage: needs patch status: open title: Improve docstring for str.index versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 13 16:24:46 2017 From: report at bugs.python.org (David Bolen) Date: Mon, 13 Feb 2017 21:24:46 +0000 Subject: [New-bugs-announce] [issue29550] Mac build-installer touch step fails after github conversion Message-ID: <1487021086.07.0.216604793795.issue29550@psf.upfronthosting.co.za> New submission from David Bolen: The "make touch" step during the Mac installer builds on the bolen-dmg build slave no longer works after the conversion to github, which breaks the daily builds on the 3.* branches. It looks like in issue 23404 Zachary disabled the touch step for the buildbots for now to avoid the issue in general builds, so perhaps the same thing should be done in build-installer pending a more general replacement of that step. ---------- components: Build messages: 287726 nosy: db3l, ned.deily, zach.ware priority: normal severity: normal status: open title: Mac build-installer touch step fails after github conversion type: compile error versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 02:10:49 2017 From: report at bugs.python.org (Wolfgang Rohdewald) Date: Tue, 14 Feb 2017 07:10:49 +0000 Subject: [New-bugs-announce] [issue29551] unittest: TestSuite.debug() does not like subTest() Message-ID: <1487056249.29.0.788036995635.issue29551@psf.upfronthosting.co.za> New submission from Wolfgang Rohdewald: the main code is appended in main.py if a test uses with self.subTest(), subTest() fails right in its first statement "if not self._outcome ..." because _outcome is None. In main.py, the commented runner.run(suite) would work correctly. If this is not meant to work, please mention it in the documentation and improve unittest's reaction. what I would find more logical from the users's point of view is something like runner.debug(suite) ---------- components: Library (Lib) files: main.py messages: 287738 nosy: wrohdewald priority: normal severity: normal status: open title: unittest: TestSuite.debug() does not like subTest() type: crash versions: Python 3.5 Added file: http://bugs.python.org/file46637/main.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 04:27:46 2017 From: report at bugs.python.org (Prudvi Mangadu) Date: Tue, 14 Feb 2017 09:27:46 +0000 Subject: [New-bugs-announce] [issue29552] Issue in Dictionary fromkeys Message-ID: <1487064466.46.0.309297636369.issue29552@psf.upfronthosting.co.za> New submission from Prudvi Mangadu: If we load the keys and values using fromkeys on dic. Later the modification in the values is reflects for all keys in the DIC, please follow the below code. ####################################################################################### PS C:\Python27> py Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> >>> input = ['1','2'] >>> result = {} >>> result = result.fromkeys(input,[]) >>>> Issue with this line >>> >>> result {'1': [], '2': []} >>> >>> result['1'].append("item1") >>> >>> result {'1': ['item1'], '2': ['item1']} >>>>>>>>>>>>>>>>>> Here result['2'] also overwrites >>> >>> result['1'].append("item2") >>> result {'1': ['item1', 'item2'], '2': ['item1', 'item2']} >>>>>>>>>>>>>>>>>> Here result['2'] also overwrites >>> >>> ####################################################################################### ---------- components: Windows messages: 287747 nosy: paul.moore, prudvibt81, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Issue in Dictionary fromkeys type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 09:59:53 2017 From: report at bugs.python.org (Christoph Stahl) Date: Tue, 14 Feb 2017 14:59:53 +0000 Subject: [New-bugs-announce] [issue29553] Argparser does not display closing parentheses in nested mutex groups Message-ID: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> New submission from Christoph Stahl: When creating nested mutually exclusive groups, all closing brackets except one are omitted. Example: parser = ArgumentParser() group = parser.add_mutually_exclusive_group() group.add_argument('-a') group.add_argument('-b') group2 = group.add_mutually_exclusive_group() group2.add_argument('-c') group2.add_argument('-d') group3 = group2.add_mutually_exclusive_group() group3.add_argument('-e') group3.add_argument('-f') prints a usage line of: usage: test.py [-h] [-a A | -b B | [-c C | -d D | [-e E | -f F] it should print something like: usage: test.py [-h] [-a A | -b B | [-c C | -d D | [-e E | -f F]]] ---------- components: Library (Lib) messages: 287776 nosy: christofsteel priority: normal severity: normal status: open title: Argparser does not display closing parentheses in nested mutex groups versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 11:00:59 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Tue, 14 Feb 2017 16:00:59 +0000 Subject: [New-bugs-announce] [issue29554] profile/pstat doc clariification Message-ID: <1487088059.45.0.492029112528.issue29554@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: profile .rst say: > Each restriction is either an integer (to select a count of lines), or a decimal fraction between 0.0 and 1.0 inclusive (to select a percentage of lines), **or a regular expression** Actually it accept a string that will be compiled to a regex. Profile.py also mention: > (i.e., in addition to the old -1, 0, 1, or 2) Which is not really helpful, to newcomers to Python who do not know what these are meant to be. Either explaining (or removing if considered old behavior that should be stopped) seem to be better alternative. See https://github.com/python/cpython/pull/88 ---------- assignee: docs at python components: Documentation messages: 287778 nosy: docs at python, mbussonn priority: normal severity: normal status: open title: profile/pstat doc clariification versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 11:02:00 2017 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 14 Feb 2017 16:02:00 +0000 Subject: [New-bugs-announce] [issue29555] Update Python Software Foundation Copyright Year Message-ID: <1487088120.64.0.260258993464.issue29555@psf.upfronthosting.co.za> New submission from Senthil Kumaran: In the attached patch, I updated the copyright year to 2017 at places it was mentioned until 2016. There was a suggestion that we remove the copyright line of Python Software Foundation from module headers since the code is already covered 1) by top level copyright mention, 2) The mention of copyright is inconsistent in modules, 3) will avoid unnecessary churn every year. This idea needs to be vetted by PSF Board and legal staff. ---------- files: pr-4.diff keywords: patch messages: 287779 nosy: orsenthil priority: normal severity: normal status: open title: Update Python Software Foundation Copyright Year versions: Python 2.7, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46638/pr-4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 11:06:53 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Tue, 14 Feb 2017 16:06:53 +0000 Subject: [New-bugs-announce] [issue29556] Remove an unused #include from bltinmodule.c Message-ID: <1487088413.61.0.441314459396.issue29556@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: This #include is added in b744ba1d14c5487576c95d0311e357b707600b47 (issue8610) and later the use of CODESET is removed in d64e8a75e5138d5e5970f0c70995ae5cc377c421 (issue9642). Found this in investigating issue29436 Add haypo as both commit is written by you ---------- components: Build messages: 287780 nosy: Chi Hsuan Yen, haypo priority: normal severity: normal status: open title: Remove an unused #include from bltinmodule.c type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 11:20:44 2017 From: report at bugs.python.org (David Wilemski) Date: Tue, 14 Feb 2017 16:20:44 +0000 Subject: [New-bugs-announce] [issue29557] binhex documentation claims unknown bug Message-ID: <1487089244.04.0.406287394607.issue29557@psf.upfronthosting.co.za> New submission from David Wilemski: The binhex documentation has a line in it that says "As of this writing, hexbin() appears to not work in all cases." This is a bit ambiguous and there is no context for what the bug may be. It appears this line is from the first commit to the hexbin function's documentation in 1995 (https://hg.python.org/cpython/rev/3911d4a89ab0#l4.40) but the commit also has no information about what this bug may be. I also see no current open bugs for the binhex module that seem related. In 2009, there was a patch for the hexbin function but I have no idea if this is the bug from the original documentation or if it was something else entirely: https://bugs.python.org/issue6369 Given this, I believe the line should be removed unless more details about the referenced buggy behavior can be found. ---------- assignee: docs at python components: Documentation messages: 287781 nosy: David Wilemski, docs at python priority: normal pull_requests: 59 severity: normal status: open title: binhex documentation claims unknown bug versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 12:17:00 2017 From: report at bugs.python.org (Javier Domingo) Date: Tue, 14 Feb 2017 17:17:00 +0000 Subject: [New-bugs-announce] [issue29558] Provide run_until_complete inside loop Message-ID: <1487092620.31.0.174365857148.issue29558@psf.upfronthosting.co.za> New submission from Javier Domingo: The current architecture of asyncio makes it really hard to combine both async and sync code. When porting a Thread based application to asyncio, the first step is usually to start merging threads to the main loop, by using `run_coroutine_threadsafe`. This works well and allows to use a single ioloop from different threads. There is another step, that usually involves the patching of libraries to work in an async way. One will typically patch the IO calls to be asyncio, and using `run_until_complete` proves useful in these situations. However, at the moment it's not possible to `run_until_complete` from an ioloop. The possibility to be able to patch sync libraries to run in asyncio is something that would help a lot the migration. This functionality would basically provide a way to continue running the ioloop until the future is resolved. Sync code -> async code -> Sync code -> Async code If you know how to have this without spawning an executor, that would be good too, in such case I would rather ask for documentation on how to do it =) ---------- components: asyncio messages: 287784 nosy: gvanrossum, txomon, yselivanov priority: normal severity: normal status: open title: Provide run_until_complete inside loop type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 13:38:59 2017 From: report at bugs.python.org (Ted Shaneyfelt) Date: Tue, 14 Feb 2017 18:38:59 +0000 Subject: [New-bugs-announce] [issue29559] Detect mouse over lines on canvas while mouse button is down Message-ID: <1487097539.49.0.870342047727.issue29559@psf.upfronthosting.co.za> New submission from Ted Shaneyfelt: There way mouse captures are done, mouse-over events seem to be disabled while dragging. This makes it difficult to provides hints as feedback, and more complicated than it should be to detect when dropping over a particular line object. Tk may not directly support it, but is there any way of getting into its guts to provide an option to re-enable mouse-over events while dragging? Or even providing a tuple with the pending mouse-overs upon release? or perhaps even simulate a mouse-up-mouse-down sequence to allow the events to propagate through and consume the noise within tkinter? Or even detect that there is a pending mouseover waiting for the mouseup event and delivering it along with the mouseup or notifying within the event that there is one pending? ---------- components: Tkinter messages: 287789 nosy: Ted Shaneyfelt2 priority: normal severity: normal status: open title: Detect mouse over lines on canvas while mouse button is down type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 14:22:08 2017 From: report at bugs.python.org (John Simmons) Date: Tue, 14 Feb 2017 19:22:08 +0000 Subject: [New-bugs-announce] [issue29560] Turtle graphics fill behavior differs between versions Message-ID: <1487100128.83.0.366459584593.issue29560@psf.upfronthosting.co.za> New submission from John Simmons: When I run the demo program on the library 24.1 documentation page to draw the star, it colors the entire star yellow, not just the parts that are show yellow on the page. This appears to be a behavior change. This is running on a Windows 7 or 10 machine with Python 3.2, 3.5, or 3.6. I have not tried this program at home, but when I run a similar program that draws and then fills 10 overlapping circles, my Linux Mint 17.3 computer at home, running IDLE in Python 3.4, fills the "interior" points inside and odd number of circles but does not fill the "exterior" points inside an even number of circles. This appears to be the behavior shown on documentation page 24.1. I would like to know what is intended to be the correct behavior and why the implementations differ. ---------- components: Tkinter messages: 287794 nosy: John Simmons priority: normal severity: normal status: open title: Turtle graphics fill behavior differs between versions type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 15:34:39 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Tue, 14 Feb 2017 20:34:39 +0000 Subject: [New-bugs-announce] [issue29561] Interactive mode gives sys.ps2 not sys.ps1 after comment-only line Message-ID: <1487104479.95.0.807901019481.issue29561@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: When you run the Python interpreter in interactive mode, get a sys.ps1 prompt (`...`), and type a comment-only or white-space-only line, the interpreter responds with a sys.ps2 prompt (`...`), instead of a sys.ps1 prompt. This seems wrong. For example: % ./python.exe Python 3.7.0a0 (default, Feb 13 2017, 16:27:07) [GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> # comment-only <<-- line A ... <<-- line B >>> <<-- line C >>> <<-- line D Line A is a comment-only line entered by the user. The interpreter responds with the sys.ps2 prompt (`...`), in line B. Line C is a null line (user enters only the Enter key, nothing else). The interpreter responds with a sys.ps1 prompt (`...`). If user enters a white-space-only line at a sys.ps1 prompt, the interpreter responds the same as if it were a comment-only line, with a sys.ps2 prompt (line B). The expected expected interpreter behaviour in response to a comment-only line or a white-space-only line, not in the midst of a compound statement, is that it be the same as to a null line, with a sys.ps1 prompt. In the context of a compound statement, the expected interpreter behaviour is that a comment-only line or a white-space-only line continue the compound statement. Entering a null line in a compound statement ends the compound statement. Another way to phrase it: the expected interpreter behaviour is that a comment-only line or white-space-only line not change the interpreter prompt: if it was sys.ps1, it remains so; if it was sys.ps2, it remains so. I have reproduced this behaviour on my build of cpython 3.7.a0, python 3.6 from MacPorts, python 2.7 from MacPorts, all on Mac OS X. I see the same behaviour in the interactive shell at python.org/shell . This makes me suspect that the Python design says my expectations are wrong. In that case, the current behaviour certainly is surprising. It should be documented. I haven't found such documentation yet. ---------- components: Interpreter Core messages: 287799 nosy: JDLH priority: normal severity: normal status: open title: Interactive mode gives sys.ps2 not sys.ps1 after comment-only line type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 21:03:06 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Wed, 15 Feb 2017 02:03:06 +0000 Subject: [New-bugs-announce] [issue29562] test_getgroups of test_posix fails (on OS X 10.10) Message-ID: <1487124186.04.0.0593189278304.issue29562@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: When I run test.test_posix.PosixTester.test_getgroups on my Mac OS X system, it fails: % ./python.exe -m unittest -v test.test_posix.PosixTester.test_getgroups test_getgroups (test.test_posix.PosixTester) ... FAIL ====================================================================== FAIL: test_getgroups (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/jdlh/workspace/cpython/Lib/test/test_posix.py", line 824, in test_getgroups self.assertTrue(not symdiff or symdiff == {posix.getegid()}) AssertionError: False is not true ---------------------------------------------------------------------- Ran 1 test in 0.013s FAILED (failures=1) Details of my system: % sw_vers ProductName: Mac OS X ProductVersion: 10.10.5 BuildVersion: 14F2109 % id -G 20 507 12 61 80 98 399 33 100 204 395 398 701 % id -G -n staff xampp everyone localaccounts admin _lpadmin com.apple.access_ssh _appstore _lpoperator _developer com.apple.access_ftp com.apple.access_screensharing com.apple.sharepoint.group.1 # I wrapped these lines similarly, to make the correspondence clearer % ./python.exe -c 'import grp,os; g={i: (n, p, i, mem) for (n, p, i, mem) in grp.getgrall()}; print(sorted([(i, g[i][0]) for i in os.getgroups()]) )' [(12, 'everyone'), (20, 'staff'), (33, '_appstore'), (61, 'localaccounts'), (80, 'admin'), (98, '_lpadmin'), (100, '_lpoperator'), (204, '_developer'), (395, 'com.apple.access_ftp'), (399, 'com.apple.access_ssh'), (507, 'xampp')] So the difference, which triggers the test failure, is that id -G is returning groups (701, 'com.apple.sharepoint.group.1'), and (398, 'com.apple.access_screensharing'), while posix.getgroups() is not. I do not yet understand why. Others say this test works on their OS X 10.10 system, so maybe it's triggered by something in my environment. Also: python3.6 from MacPorts, and python2.7 from MacPorts, return the same set of groupids as does the dev build of python3.7. This bug affects the same test, and the same posix.getgroups() call, as http://bugs.python.org/issue17557 "test_getgroups of test_posix can fail on OS X 10.8 if more than 16 groups" (2013-2014, closed). But I think it is a different problem: issue17557 is related to how posix.getgroups() deals with large numbers of groups, and it is fixed. I would appreciate help in getting this test to pass. Maybe my environment is wrong, in which case I should fix my environment. But maybe the cpython code is sensitive to some detail of my environment, in which case perhaps I should fix the cpython code. ---------- components: Tests messages: 287806 nosy: JDLH priority: normal severity: normal status: open title: test_getgroups of test_posix fails (on OS X 10.10) type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 21:46:18 2017 From: report at bugs.python.org (Jim DeLaHunt) Date: Wed, 15 Feb 2017 02:46:18 +0000 Subject: [New-bugs-announce] [issue29563] Update Devguide about building documentation. Message-ID: <1487126778.41.0.112837375413.issue29563@psf.upfronthosting.co.za> New submission from Jim DeLaHunt: The Devguide section 7.5.1 "Building the documentation" / "Using make / make.bat" is out of date. The document lists 10 documentation targets for `make`. The Doc/Makefile lists 17. One important omission is `make check`, which looks for errors in reStructuredText syntax, using `rstlint.py`. It's important for contributors to know about and to run `make check`, because with the move to GitHub, the project is running make check after pulling in new code. If contributors haven't cleaned up their submissions, the build fails. I suggest that the following improvements be made: 1. rewrite the bullet list "Available make targets are:" in 7.5.1 https://cpython-devguide.readthedocs.io/documenting.html#using-make-make-bat to match the list of targets in Doc/Makefile:21-38. 2. add a comment that `make help` will give the most up-to-date list of targets from the makefile, which might be better than the list in the Devguide. 3. add `make help` to both Doc/Makefile:21-38 and Devguide 7.5.1. 4. add to Devguide 6.3. "Helping with the Developer?s Guide" an instruction to run `make check` before submitting a pull request to the Devguide. ---------- assignee: docs at python components: Documentation messages: 287808 nosy: JDLH, docs at python priority: normal severity: normal status: open title: Update Devguide about building documentation. type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 14 22:11:36 2017 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Wed, 15 Feb 2017 03:11:36 +0000 Subject: [New-bugs-announce] [issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket Message-ID: <1487128296.48.0.945171350707.issue29564@psf.upfronthosting.co.za> New submission from David Ford (FirefighterBlu3): the following warning is incorrectly reported as initiated at psycopg2/extras.py:314, it actually occurs inside the Twilio python module. /usr/lib/python3.6/site-packages/psycopg2/extras.py:314: ResourceWarning: unclosed ts = super(NamedTupleCursor, self).fetchall() namedtuple_Record:19: ResourceWarning: unclosed This is the snippet of my code which makes the Twilio API call over https (noted by the >>> line). # get failed/undelivered with (yield from self.aiopg_pool.cursor(cursor_factory=psycopg2.extras.NamedTupleCursor)) as c: yield from c.execute(stmt_bad, (id,)) rows = yield from c.fetchall() # make calls to twilio and fetch failure reasons for r in rows: >>> msg = self._twilio.messages.get(r.delivery_id) errors[r.delivery_id] = r.recipient, msg.error_code, msg.error_message my tool uses crossbar.io's python-autobahn asyncio classes which do not use threading to my knowledge. psycopg2/pool.py does use threading. python-twilio does not use threading either. ---------- messages: 287810 nosy: David Ford (FirefighterBlu3) priority: normal severity: normal status: open title: ResourceWarning tracking is attaching incorrect file:position to unclosed socket type: resource usage versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 04:48:34 2017 From: report at bugs.python.org (Igor Kudrin) Date: Wed, 15 Feb 2017 09:48:34 +0000 Subject: [New-bugs-announce] [issue29565] Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) Message-ID: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za> New submission from Igor Kudrin: It looks like resolving https://bugs.python.org/issue20160 didn't fix all the issues. When a large struct is used as a parameter, a reference to the object itself is passed to the function, not a reference to a temporary copy, as it is required in https://msdn.microsoft.com/en-us/library/zthk2dkh.aspx. Here is the reproduction sample: === Sample.c: === typedef struct { int v[3]; } Data; __declspec(dllexport) void Cripple(Data data) { data.v[0] = 0; } === Sample.py === from ctypes import * class Data(Structure): _fields_ = [("v", c_int * 3)] lib = cdll.LoadLibrary('Sample.dll') getattr(lib, 'Cripple').argtypes = [Data] data = Data() data.v[0] = 42 lib.Cripple(data) assert data.v[0] == 42 print "OK" === repro.cmd === call "%VS140COMNTOOLS%/../../VC/vcvarsall.bat" x86_amd64 cl /LD Sample.c python Sample.py ---------- components: Windows, ctypes messages: 287831 nosy: Igor Kudrin, christian.heimes, doko, mark.dickinson, meador.inge, paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware priority: normal severity: normal status: open title: Still broken ctypes calling convention on MSVC / 64-bit Windows (large structs) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 07:21:05 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Feb 2017 12:21:05 +0000 Subject: [New-bugs-announce] [issue29566] binhex() creates files with mixed line endings Message-ID: <1487161265.61.0.450348509296.issue29566@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: binhex.binhex() creates files with mixed line endings in Python 3. The header line '(This file must be converted with BinHex 4.0)' is separated from the data by LFs, but the data is split for lines by CRs. >>> import binhex >>> with open('inp', 'wb') as f: f.write(bytes(range(256))) ... 256 >>> binhex.binhex('inp', 'outp') >>> for line in open('outp', 'rb').read().splitlines(True): print(repr(line)) ... b'(This file must be converted with BinHex 4.0)\r' b'\r' b':!fPZF!!rN!J!N!3"!*!&*VF!!3)$"!8\'"`J*#JX-$3i2%"%5%a39&KFB\'4SE("d\n' b'H(b!K)L-N*5BR+#NU+b`Y,Lm`-6)c0$8f0cJj1MXm26ir3%d4&4NG)58T,6%e\n' b'16e"48P0899CA@&PD at eaGAPpJB@*MC\'9QCfKTDQYXE at j[F(&bFh4eGRGiHATlI(e\n' b'qIi#"JS1%KBD(L)Q+Lib0MSq3!*\'5Nj59PTHBQCUER*fHRk#KSU1NTDDRU+QUUkb\n' b'YVUq`XE+cY, at fYlLjZVZm[Ekr`-(#`m6&aXI)bFV,c-h1cp$4dY28eGEAf0RDfpc\n' b'GhYrJiH,Mj1AQjqMTkZ[XlHl[m2(bmr6ep[IiqIVlr2hqrhj9!!!:\n' In Python 2 the output file was file object usually opened in text mode. Newline characters were translated to platform-depending line endings: CRLF on Windows, LF on classic Mac OS. In Python 2 the output file is binary stream that doesn't do any newline translations. The last related commit is 34a042d301d6ab88645046a6dfa6c38265ca4b39 with Guido's message "This is the last time I fix binhex. If it breaks again it goes in the dustbin." ---------- components: macOS messages: 287849 nosy: gvanrossum, ned.deily, ronaldoussoren, serhiy.storchaka priority: normal severity: normal status: open title: binhex() creates files with mixed line endings type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 08:55:12 2017 From: report at bugs.python.org (Chi Hsuan Yen) Date: Wed, 15 Feb 2017 13:55:12 +0000 Subject: [New-bugs-announce] [issue29567] Allow argparse to be used in setup.py Message-ID: <1487166912.35.0.34823901081.issue29567@psf.upfronthosting.co.za> New submission from Chi Hsuan Yen: When proposing a fix for issue29442, I got another issue - argparse can't be used in setup.py for native (non-cross) builds because argparse imports gettext and gettext imports struct. I'll propose a fix for that. ---------- components: Build messages: 287854 nosy: Chi Hsuan Yen priority: normal severity: normal status: open title: Allow argparse to be used in setup.py type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 09:53:02 2017 From: report at bugs.python.org (Jerry Dimitrov) Date: Wed, 15 Feb 2017 14:53:02 +0000 Subject: [New-bugs-announce] [issue29568] undefined parsing behavior with the old style string formatting Message-ID: <1487170382.81.0.823573985019.issue29568@psf.upfronthosting.co.za> New submission from Jerry Dimitrov: Hello everyone, This is my first bug report to the python project, so please excuse me if the metadata for this particular issue is not 100% accurate. Today I noticed (with the help from couple of people in IRC) a strange behavior in the python string formatting functionality. Consider the following code snippets: ``` '%(a)s %(b)' % {'a': '1', 'b': '2'} # result: Traceback (most recent call last): File "", line 1, in ValueError: incomplete format ``` ``` '%(a) %(b)s' % {'a': '1', 'b': '2'} # result: '%(b)s' # expected result: Traceback (most recent call last): File "", line 1, in ValueError: incomplete format ``` It seems that there is some kind of inconsistent (undefined) behavior, during the parsing of the type character for the formatted string (tested across all major python 2.x/3.x versions). According to the documentation for string formatting and the relevant PEPs, there is no additional info about this particular case. I want to say thank you to Yhg1s, JustASlacker, Jerub and lz1irq for discovering this 'bug/feature' and the additional information about it. Please let me know if this is a bug, since I am not 100% sure if this is the case. Thanks in advance for your time! Best Regards, Jerry ---------- components: Interpreter Core messages: 287857 nosy: Jerry Dimitrov priority: normal severity: normal status: open title: undefined parsing behavior with the old style string formatting type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 09:54:10 2017 From: report at bugs.python.org (slytomcat) Date: Wed, 15 Feb 2017 14:54:10 +0000 Subject: [New-bugs-announce] [issue29569] threading.Timer class: Continue periodical execution till action returns True Message-ID: <1487170450.59.0.269062661251.issue29569@psf.upfronthosting.co.za> New submission from slytomcat: I think that functionality of threading.Timer class can be easily extended to generate the sequence of runs with specified period. The idea comes from the GLib.timeout_add function. Run method of threading.Timer should look like: def run(self): """Continue execution after wait till function returns True""" while(not self.finished.wait(self.interval)): if not self.function(*self.args, **self.kwargs): break self.finished.set() ---------- components: Library (Lib) messages: 287858 nosy: slytomcat priority: normal severity: normal status: open title: threading.Timer class: Continue periodical execution till action returns True type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 11:54:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Feb 2017 16:54:36 +0000 Subject: [New-bugs-announce] [issue29570] Windows Buildbot 2.7 is broken Message-ID: <1487177676.07.0.331471484641.issue29570@psf.upfronthosting.co.za> New submission from STINNER Victor: Example of failure: http://buildbot.python.org/all/builders/AMD64%20Windows8%202.7/builds/67/steps/test/logs/stdio FAIL: test_incrementaldecoder (test.test_codecencodings_iso2022.Test_ISO2022_KR) => failure with newline, maybe caused by the migration to GitHub: see issue #29530 ERROR: test_bug_1727780 (test.test_random.WichmannHill_TestBasicOps) ImportError: No module named random => ... no idea, can it be related to the commit 0f48ecddfb79ef541500ecfcbda0b4178af1cc29 which only changes a comment!? ---------- components: Tests, Windows keywords: buildbot messages: 287863 nosy: haypo, inada.naoki, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows Buildbot 2.7 is broken versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 12:29:11 2017 From: report at bugs.python.org (Jaysinh shukla) Date: Wed, 15 Feb 2017 17:29:11 +0000 Subject: [New-bugs-announce] [issue29571] test_re is failing when local is set for `en_IN` Message-ID: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za> New submission from Jaysinh shukla: Description: A test case is failing while running `./python -m test -v test_re`. Traceback: $>./python -m test -v test_re == CPython 3.7.0a0 (default, Feb 15 2017, 22:28:32) [GCC 5.4.0 20160609] == Linux-4.4.0-62-generic-x86_64-with-debian-stretch-sid little-endian == hash algorithm: siphash24 64bit == cwd: /home/bigj/Jaysinh/cpython_git/cpython/build/test_python_613 == encodings: locale=UTF-8, FS=utf-8 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) Run tests sequentially 0:00:00 [1/1] test_re test_re_benchmarks (test.test_re.ExternalTests) re_tests benchmarks ... ok test_re_tests (test.test_re.ExternalTests) re_tests test suite ... ok test_overlap_table (test.test_re.ImplementationTest) ... ok test_bytes (test.test_re.PatternReprTests) ... ok test_inline_flags (test.test_re.PatternReprTests) ... ok test_locale (test.test_re.PatternReprTests) ... ok test_long_pattern (test.test_re.PatternReprTests) ... ok test_multiple_flags (test.test_re.PatternReprTests) ... ok test_quotes (test.test_re.PatternReprTests) ... ok test_single_flag (test.test_re.PatternReprTests) ... ok test_unicode_flag (test.test_re.PatternReprTests) ... ok test_unknown_flags (test.test_re.PatternReprTests) ... ok test_without_flags (test.test_re.PatternReprTests) ... ok test_anyall (test.test_re.ReTests) ... ok test_ascii_and_unicode_flag (test.test_re.ReTests) ... ok test_backref_group_name_in_exception (test.test_re.ReTests) ... ok test_basic_re_sub (test.test_re.ReTests) ... ok test_big_codesize (test.test_re.ReTests) ... ok test_bigcharset (test.test_re.ReTests) ... ok test_bug_113254 (test.test_re.ReTests) ... ok test_bug_114660 (test.test_re.ReTests) ... ok test_bug_117612 (test.test_re.ReTests) ... ok test_bug_1661 (test.test_re.ReTests) ... ok test_bug_16688 (test.test_re.ReTests) ... ok test_bug_20998 (test.test_re.ReTests) ... ok test_bug_2537 (test.test_re.ReTests) ... ok test_bug_29444 (test.test_re.ReTests) ... ok test_bug_3629 (test.test_re.ReTests) ... ok test_bug_418626 (test.test_re.ReTests) ... ok test_bug_448951 (test.test_re.ReTests) ... ok test_bug_449000 (test.test_re.ReTests) ... ok test_bug_449964 (test.test_re.ReTests) ... ok test_bug_462270 (test.test_re.ReTests) ... ok test_bug_527371 (test.test_re.ReTests) ... ok test_bug_581080 (test.test_re.ReTests) ... ok test_bug_612074 (test.test_re.ReTests) ... ok test_bug_6509 (test.test_re.ReTests) ... ok test_bug_6561 (test.test_re.ReTests) ... ok test_bug_725106 (test.test_re.ReTests) ... ok test_bug_725149 (test.test_re.ReTests) ... ok test_bug_764548 (test.test_re.ReTests) ... ok test_bug_817234 (test.test_re.ReTests) ... ok test_bug_926075 (test.test_re.ReTests) ... ok test_bug_931848 (test.test_re.ReTests) ... ok test_bytes_str_mixing (test.test_re.ReTests) ... ok test_category (test.test_re.ReTests) ... ok test_character_set_errors (test.test_re.ReTests) ... ok test_compile (test.test_re.ReTests) ... ok test_constants (test.test_re.ReTests) ... ok test_dealloc (test.test_re.ReTests) ... ok test_debug_flag (test.test_re.ReTests) ... ok test_dollar_matches_twice (test.test_re.ReTests) $ matches the end of string, and just before the terminating ... ok test_empty_array (test.test_re.ReTests) ... ok test_enum (test.test_re.ReTests) ... ok test_error (test.test_re.ReTests) ... ok test_expand (test.test_re.ReTests) ... ok test_finditer (test.test_re.ReTests) ... ok test_flags (test.test_re.ReTests) ... ok test_getattr (test.test_re.ReTests) ... ok test_getlower (test.test_re.ReTests) ... ok test_group (test.test_re.ReTests) ... ok test_group_name_in_exception (test.test_re.ReTests) ... ok test_groupdict (test.test_re.ReTests) ... ok test_ignore_case (test.test_re.ReTests) ... ok test_ignore_case_range (test.test_re.ReTests) ... ok test_ignore_case_set (test.test_re.ReTests) ... ok test_inline_flags (test.test_re.ReTests) ... ok test_issue17998 (test.test_re.ReTests) ... ok test_keep_buffer (test.test_re.ReTests) ... ok test_keyword_parameters (test.test_re.ReTests) ... ok test_large_search (test.test_re.ReTests) ... ok test_large_subn (test.test_re.ReTests) ... ok test_locale_caching (test.test_re.ReTests) ... skipped 'test needs en_US.iso88591 locale' test_locale_flag (test.test_re.ReTests) ... FAIL test_lookahead (test.test_re.ReTests) ... ok test_lookbehind (test.test_re.ReTests) ... ok test_match_getitem (test.test_re.ReTests) ... ok test_match_repr (test.test_re.ReTests) ... ok test_misc_errors (test.test_re.ReTests) ... ok test_multiple_repeat (test.test_re.ReTests) ... ok test_not_literal (test.test_re.ReTests) ... ok test_nothing_to_repeat (test.test_re.ReTests) ... ok test_other_escapes (test.test_re.ReTests) ... ok test_pattern_compare (test.test_re.ReTests) ... ok test_pattern_compare_bytes (test.test_re.ReTests) ... ok test_pickling (test.test_re.ReTests) ... ok test_qualified_re_split (test.test_re.ReTests) ... ok test_qualified_re_sub (test.test_re.ReTests) ... ok test_re_escape (test.test_re.ReTests) ... ok test_re_escape_byte (test.test_re.ReTests) ... ok test_re_escape_non_ascii (test.test_re.ReTests) ... ok test_re_escape_non_ascii_bytes (test.test_re.ReTests) ... ok test_re_findall (test.test_re.ReTests) ... ok test_re_fullmatch (test.test_re.ReTests) ... ok test_re_groupref (test.test_re.ReTests) ... ok test_re_groupref_exists (test.test_re.ReTests) ... ok test_re_groupref_overflow (test.test_re.ReTests) ... ok test_re_match (test.test_re.ReTests) ... ok test_re_split (test.test_re.ReTests) ... ok test_re_subn (test.test_re.ReTests) ... ok test_repeat_minmax (test.test_re.ReTests) ... ok test_repeat_minmax_overflow (test.test_re.ReTests) ... ok test_repeat_minmax_overflow_maxrepeat (test.test_re.ReTests) ... ok test_scanner (test.test_re.ReTests) ... ok test_scoped_flags (test.test_re.ReTests) ... ok test_search_coverage (test.test_re.ReTests) ... ok test_search_dot_unicode (test.test_re.ReTests) ... ok test_search_star_plus (test.test_re.ReTests) ... ok test_special_escapes (test.test_re.ReTests) ... ok test_sre_byte_class_literals (test.test_re.ReTests) ... ok test_sre_byte_literals (test.test_re.ReTests) ... ok test_sre_character_class_literals (test.test_re.ReTests) ... ok test_sre_character_literals (test.test_re.ReTests) ... ok test_stack_overflow (test.test_re.ReTests) ... ok test_string_boundaries (test.test_re.ReTests) ... ok test_sub_template_numeric_escape (test.test_re.ReTests) ... ok test_symbolic_groups (test.test_re.ReTests) ... ok test_symbolic_refs (test.test_re.ReTests) ... ok test_unlimited_zero_width_repeat (test.test_re.ReTests) ... ok test_weakref (test.test_re.ReTests) ... ok ====================================================================== FAIL: test_locale_flag (test.test_re.ReTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/bigj/Jaysinh/cpython_git/cpython/Lib/test/test_re.py", line 1422, in test_locale_flag self.assertTrue(pat.match(bletter)) AssertionError: None is not true ---------------------------------------------------------------------- Ran 120 tests in 2.079s FAILED (failures=1, skipped=1) test test_re failed test_re failed 1 test failed: test_re Total duration: 2 sec Tests result: FAILURE Local value: $>locale LANG=en_IN LANGUAGE=en_IN:en LC_CTYPE="en_IN" LC_NUMERIC="en_IN" LC_TIME="en_IN" LC_COLLATE="en_IN" LC_MONETARY="en_IN" LC_MESSAGES="en_IN" LC_PAPER="en_IN" LC_NAME="en_IN" LC_ADDRESS="en_IN" LC_TELEPHONE="en_IN" LC_MEASUREMENT="en_IN" LC_IDENTIFICATION="en_IN" LC_ALL= Operating system: Ubuntu 16.04 LTS(64 bit) ---------- components: Regular Expressions messages: 287867 nosy: ezio.melotti, jaysinh.shukla, mrabarnett priority: normal severity: normal status: open title: test_re is failing when local is set for `en_IN` versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 13:06:12 2017 From: report at bugs.python.org (Zachary Ware) Date: Wed, 15 Feb 2017 18:06:12 +0000 Subject: [New-bugs-announce] [issue29572] Upgrade installers to OpenSSL 1.0.2k Message-ID: <1487181972.09.0.437715679754.issue29572@psf.upfronthosting.co.za> New submission from Zachary Ware: It's that time once again (as of a few weeks ago). This one doesn't seem to be a high severity update, though. Also, it seems that 1.1.0e is due tomorrow; I'm not sure if that means 1.0.2l will also come out tomorrow, so we'll want to hold off until at least then anyway. This is mostly just a reminder for now. ---------- assignee: christian.heimes components: Installation, SSL, Windows, macOS messages: 287877 nosy: christian.heimes, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware priority: high severity: normal status: open title: Upgrade installers to OpenSSL 1.0.2k type: security versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 16:21:19 2017 From: report at bugs.python.org (Richard Xia) Date: Wed, 15 Feb 2017 21:21:19 +0000 Subject: [New-bugs-announce] [issue29573] NamedTemporaryFile with delete=True should not fail if file already deleted Message-ID: <1487193679.14.0.35599130933.issue29573@psf.upfronthosting.co.za> New submission from Richard Xia: Here is a very short program to demonstrate what I'm seeing: >>> import tempfile >>> import os >>> with tempfile.NamedTemporaryFile(delete=True) as fp: ... print(fp.name) ... os.system('rm {}'.format(fp.name)) /tmp/tmpomw0udc6 0 Traceback (most recent call last): File "", line 3, in File "/usr/local/lib/python3.6/tempfile.py", line 502, in __exit__ self.close() File "/usr/local/lib/python3.6/tempfile.py", line 509, in close self._closer.close() File "/usr/local/lib/python3.6/tempfile.py", line 446, in close unlink(self.name) FileNotFoundError: [Errno 2] No such file or directory: '/tmp/tmpomw0udc6' In my specific use case, I am shelling out to another program (binutils' objcopy) and passing the path of the NamedTemporaryFile as the output file. objcopy apparently deletes the output file if it encounters an error, which causes NamedTemporaryFile's exit method to fail when it tries to delete the file. While I can work around this by using delete=False and manually doing the cleanup on my own, it's less elegant than being able to rely on the normal context manager exit. ---------- components: IO messages: 287888 nosy: richardxia priority: normal severity: normal status: open title: NamedTemporaryFile with delete=True should not fail if file already deleted type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 17:50:47 2017 From: report at bugs.python.org (Dave Anderson) Date: Wed, 15 Feb 2017 22:50:47 +0000 Subject: [New-bugs-announce] [issue29574] python-3.6.0.tgz permissions borked Message-ID: <1487199047.25.0.291984947125.issue29574@psf.upfronthosting.co.za> New submission from Dave Anderson: Downloaded https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tgz Extracted on CentOS6 with sudo tar -xf Python-3.6.0.tgz Result: [vagrant at developer tmp]$ ls -l Python-3.6.0 ls: cannot access Python-3.6.0/Tools: Permission denied ls: cannot access Python-3.6.0/config.guess: Permission denied ls: cannot access Python-3.6.0/pyconfig.h.in: Permission denied ls: cannot access Python-3.6.0/config.sub: Permission denied ls: cannot access Python-3.6.0/configure.ac: Permission denied ls: cannot access Python-3.6.0/Python: Permission denied ls: cannot access Python-3.6.0/Objects: Permission denied ls: cannot access Python-3.6.0/PCbuild: Permission denied ls: cannot access Python-3.6.0/Include: Permission denied ls: cannot access Python-3.6.0/aclocal.m4: Permission denied ls: cannot access Python-3.6.0/configure: Permission denied ls: cannot access Python-3.6.0/Misc: Permission denied ls: cannot access Python-3.6.0/Makefile.pre.in: Permission denied ls: cannot access Python-3.6.0/setup.py: Permission denied ls: cannot access Python-3.6.0/Lib: Permission denied ls: cannot access Python-3.6.0/PC: Permission denied ls: cannot access Python-3.6.0/Doc: Permission denied ls: cannot access Python-3.6.0/README: Permission denied ls: cannot access Python-3.6.0/Programs: Permission denied ls: cannot access Python-3.6.0/install-sh: Permission denied ls: cannot access Python-3.6.0/LICENSE: Permission denied ls: cannot access Python-3.6.0/Modules: Permission denied ls: cannot access Python-3.6.0/Grammar: Permission denied ls: cannot access Python-3.6.0/Parser: Permission denied ls: cannot access Python-3.6.0/Mac: Permission denied total 0 -????????? ? ? ? ? ? aclocal.m4 -????????? ? ? ? ? ? config.guess -????????? ? ? ? ? ? config.sub -????????? ? ? ? ? ? configure -????????? ? ? ? ? ? configure.ac d????????? ? ? ? ? ? Doc d????????? ? ? ? ? ? Grammar d????????? ? ? ? ? ? Include -????????? ? ? ? ? ? install-sh d????????? ? ? ? ? ? Lib -????????? ? ? ? ? ? LICENSE d????????? ? ? ? ? ? Mac -????????? ? ? ? ? ? Makefile.pre.in d????????? ? ? ? ? ? Misc d????????? ? ? ? ? ? Modules d????????? ? ? ? ? ? Objects d????????? ? ? ? ? ? Parser d????????? ? ? ? ? ? PC d????????? ? ? ? ? ? PCbuild d????????? ? ? ? ? ? Programs -????????? ? ? ? ? ? pyconfig.h.in d????????? ? ? ? ? ? Python -????????? ? ? ? ? ? README -????????? ? ? ? ? ? setup.py d????????? ? ? ? ? ? Tools [vagrant at developer tmp]$ Same operation with Python 3.5.2 tgz file downloaded from same location: [vagrant at developer tmp]$ ls -l Python-3.5.2 total 1008 -rw-r--r-- 1 1000 1000 8464 Jun 25 2016 aclocal.m4 -rwxr-xr-x 1 1000 1000 42856 Jun 25 2016 config.guess -rwxr-xr-x 1 1000 1000 35740 Jun 25 2016 config.sub -rwxr-xr-x 1 1000 1000 474932 Jun 25 2016 configure -rw-r--r-- 1 1000 1000 155069 Jun 25 2016 configure.ac drwxrwxr-x 18 1000 1000 4096 Jun 25 2016 Doc drwxrwxr-x 2 1000 1000 4096 Jun 25 2016 Grammar drwxrwxr-x 2 1000 1000 4096 Jun 25 2016 Include -rwxr-xr-x 1 1000 1000 7122 Jun 25 2016 install-sh drwxrwxr-x 46 1000 1000 12288 Jun 25 2016 Lib -rw-r--r-- 1 1000 1000 12767 Jun 25 2016 LICENSE drwxrwxr-x 8 1000 1000 4096 Jun 25 2016 Mac -rw-r--r-- 1 1000 1000 58449 Jun 25 2016 Makefile.pre.in drwxrwxr-x 2 1000 1000 4096 Jun 25 2016 Misc drwxrwxr-x 11 1000 1000 4096 Jun 25 2016 Modules drwxrwxr-x 4 1000 1000 4096 Jun 25 2016 Objects drwxrwxr-x 2 1000 1000 4096 Jun 25 2016 Parser drwxrwxr-x 4 1000 1000 4096 Jun 25 2016 PC drwxrwxr-x 2 1000 1000 4096 Jun 25 2016 PCbuild drwxrwxr-x 2 1000 1000 4096 Jun 25 2016 Programs -rw-r--r-- 1 1000 1000 41897 Jun 25 2016 pyconfig.h.in drwxrwxr-x 3 1000 1000 4096 Jun 25 2016 Python -rw-r--r-- 1 1000 1000 8060 Jun 25 2016 README -rw-r--r-- 1 1000 1000 99778 Jun 25 2016 setup.py drwxrwxr-x 22 1000 1000 4096 Jun 25 2016 Tools [vagrant at developer tmp]$ ---------- components: Build messages: 287891 nosy: Dave_Anderson priority: normal severity: normal status: open title: python-3.6.0.tgz permissions borked versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 17:59:20 2017 From: report at bugs.python.org (Joachim) Date: Wed, 15 Feb 2017 22:59:20 +0000 Subject: [New-bugs-announce] [issue29575] doc 17.2.1: basic Pool example is too basic Message-ID: <1487199560.37.0.441891248359.issue29575@psf.upfronthosting.co.za> New submission from Joachim: The ?basic example of data parallelism using Pool? is too basic. It demonstrates the syntax, but otherwise makes no sense, and therefore is potentially confusing. It is blatant nonsense to run 5 processes when there are only 3 data to be treated. Let me suggest the following: from multiprocessing import Pool import time def f(x): time.sleep(1) return x*x if __name__ == '__main__': start_time = time.time() with Pool(4) as p: print(p.map(f, range(20))) print("elapsed wall time: ", time.time()-start_time) The sleep command makes f representative for a function that takes significant time to execute. Printing the elapsed time shows the user that the 20 calls of f have indeed taken place in parallel. ---------- assignee: docs at python components: Documentation messages: 287895 nosy: docs at python, j5w6 priority: normal severity: normal status: open title: doc 17.2.1: basic Pool example is too basic versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 20:27:34 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Thu, 16 Feb 2017 01:27:34 +0000 Subject: [New-bugs-announce] [issue29576] Improve some deprecations in the importlib Message-ID: <1487208454.1.0.000568467436348.issue29576@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: A couple of function in importlib are marked as deprecated in the documentation but do not raise deprecation warnings. As the same time it would be great to improve some deprecation warnings and docstring to include the version since when this is deprecated. This should be take care of by https://github.com/python/cpython/pull/32 ---------- assignee: docs at python components: Documentation messages: 287908 nosy: docs at python, mbussonn priority: normal pull_requests: 88 severity: normal status: open title: Improve some deprecations in the importlib type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 15 21:09:44 2017 From: report at bugs.python.org (Ethan Furman) Date: Thu, 16 Feb 2017 02:09:44 +0000 Subject: [New-bugs-announce] [issue29577] Enum: mixin classes don't mix well with already mixed Enums Message-ID: <1487210984.19.0.348647583319.issue29577@psf.upfronthosting.co.za> New submission from Ethan Furman: Consider: -------- class AllEnum(Enum): @classattr def ALL(cls): members = list(cls) all_value = None if members: all_value = members[0] for member in members[1:]: all_value |= member cls.ALL = all_value return all_value class Color(AllEnum, Flag): RED = auto() BLUE = auto() GREEN = auto() class IntColor(AllEnum, IntFlag): RED = auto() BLUE = auto() GREEN = auto() -------- The Color class works fine, but the IntColor fails. This is due to the way the base data type and __new__ method is discovered. If we switch the order of the bases class IntColor(IntFlag, AllEnum) it works, but having to put the mixin class last is both bizarre and unworkable when the mixin should be overriding behavior. ---------- assignee: ethan.furman components: Library (Lib) messages: 287910 nosy: barry, eli.bendersky, ethan.furman priority: normal severity: normal status: open title: Enum: mixin classes don't mix well with already mixed Enums versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 03:56:15 2017 From: report at bugs.python.org (Big Stone) Date: Thu, 16 Feb 2017 08:56:15 +0000 Subject: [New-bugs-announce] [issue29578] "python.exe t2.py" doesn't work the same on Pythn-3.6 as Python-3.5 Message-ID: <1487235375.21.0.440893966448.issue29578@psf.upfronthosting.co.za> New submission from Big Stone: Hi, I have two file "t1.py" and "t2.py" in the same directory. "t2.py" can't import "t1.py" when launched from python.exe on Python-3.6. it was ok on Python-3.5 (all other things being equal). And it's ok when launched from IDLE. Has there been a volontary change ? t1.py: print("i am t1") t2.py: import t1 print("I am t2") result (on WinPython-3.6): python.Exe C:\WinPython\basedir36\buildZero\winpython-64bit-3.6.x.2\test\t2.py Traceback (most recent call last): File "C:\WinPython\basedir36\buildZero\winpython-64bit-3.6.x.2\test\t2.py", line 1, in import t1 ModuleNotFoundError: No module named 't1' C:\WinPython\basedir36\buildZero\winpython-64bit-3.6.x.2\scripts> nota: Winpython specificity is the use of python._pth, with: python36.zip DLLs Lib . import site ---------- components: Windows messages: 287919 nosy: Big Stone, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: "python.exe t2.py" doesn't work the same on Pythn-3.6 as Python-3.5 type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 04:48:36 2017 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Feb 2017 09:48:36 +0000 Subject: [New-bugs-announce] [issue29579] Windows Python 3.7 installer broken by README.txt renamed to README.rst Message-ID: <1487238516.39.0.726696732648.issue29579@psf.upfronthosting.co.za> New submission from STINNER Victor: Copy of https://github.com/python/cpython/pull/104#issuecomment-280174576 --- The Windows installer build picks up this readme file and distributes it as readme.txt (see Tools/msi/exe/exe_files.wxs, which now needs fixing). I vote we should keep both so that we can distribute the file without rst formatting. (As an aside, we also read the /LICENSE file, so if someone wants to come in and "fix" that too then they'll also need to update the installer.) --- README.txt was renamed to README.rst by the PR#2: https://github.com/python/cpython/pull/2 But README.rst was then modified by PR #70, PR #73 and #21. ---------- components: Build, Windows messages: 287924 nosy: georg.brandl, haypo, ned.deily, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows Python 3.7 installer broken by README.txt renamed to README.rst versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 12:32:50 2017 From: report at bugs.python.org (Stefan Pochmann) Date: Thu, 16 Feb 2017 17:32:50 +0000 Subject: [New-bugs-announce] [issue29580] "Built-in Functions" not being functions Message-ID: <1487266370.66.0.0116645570203.issue29580@psf.upfronthosting.co.za> New submission from Stefan Pochmann: About https://docs.python.org/3/library/functions.html: The title "Built-in Functions", the table header "Built-in Functions" and the "functions" in the URL all suggest that what's on this page are functions. But many things on that page don't appear to be functions, like "range" or "dict". They appear to be callable types instead. For example "range": >>> type(range) >>> import types >>> isinstance(range, types.FunctionType) False >>> isinstance(range, types.BuiltinFunctionType) False Compare with "abs": >>> type(abs) >>> isinstance(abs, types.FunctionType) False >>> isinstance(abs, types.BuiltinFunctionType) True The text between title and table talks about "functions and types", but the title/tableheader/URL disagree. Also, the table is wrong in saying that "abs()" etc are functions. Should say "abs" instead, i.e., remove the "()". Many, like "abs", aren't even allowed to be called like that, as it results in "TypeError: abs() takes exactly one argument (0 given)". ---------- assignee: docs at python components: Documentation messages: 287961 nosy: Stefan Pochmann, docs at python priority: normal severity: normal status: open title: "Built-in Functions" not being functions type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 13:54:07 2017 From: report at bugs.python.org (Nate Soares) Date: Thu, 16 Feb 2017 18:54:07 +0000 Subject: [New-bugs-announce] [issue29581] __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta) Message-ID: <1487271247.7.0.447487107459.issue29581@psf.upfronthosting.co.za> New submission from Nate Soares: I believe I've found a bug (or, at least, critical shortcoming) in the way that python 3.6's __init_subclass__ interacts with abc.ABCMeta (and, presumably, most other metaclasses in the standard library). In short, if a class subclasses both an abstract class and a class-that-uses-__init_subclass__, and the __init_subclass__ uses keyword arguments, then this will often lead to TypeErrors (because the metaclass gets confused by the keyword arguments to __new__ that were meant for __init_subclass__). Here's an example of the failure. This code: from abc import ABCMeta class Initifier: def __init_subclass__(cls, x=None, **kwargs): super().__init_subclass__(**kwargs) print('got x', x) class Abstracted(metaclass=ABCMeta): pass class Thingy(Abstracted, Initifier, x=1): pass thingy = Thingy() raises this TypeError when run: Traceback (most recent call last): File "", line 10, in class Thingy(Abstracted, Initifier, x=1): TypeError: __new__() got an unexpected keyword argument 'x' See http://stackoverflow.com/questions/42281697/typeerror-when-combining-abcmeta-with-init-subclass-in-python-3-6 for further discussion. ---------- messages: 287966 nosy: Nate Soares priority: normal severity: normal status: open title: __init_subclass__ causes TypeError when used with standard library metaclasses (such as ABCMeta) type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 14:45:02 2017 From: report at bugs.python.org (Zachary Ware) Date: Thu, 16 Feb 2017 19:45:02 +0000 Subject: [New-bugs-announce] [issue29582] Add Python coverage make target(s) Message-ID: <1487274302.16.0.894945109017.issue29582@psf.upfronthosting.co.za> New submission from Zachary Ware: Inspired by Barry's post to core-workflow, I'd like to suggest renaming the current "coverage" target to "ccoverage", adding a "pycoverage" target that does what .travis.yml currently does for coverage (minus uploading to codecov), and a "fullcoverage" target that does both "ccoverage" and "pycoverage". ---------- components: Build messages: 287968 nosy: barry, zach.ware priority: normal severity: normal stage: needs patch status: open title: Add Python coverage make target(s) type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 19:03:48 2017 From: report at bugs.python.org (Lane Campbell) Date: Fri, 17 Feb 2017 00:03:48 +0000 Subject: [New-bugs-announce] [issue29583] Python 3.6 won't install on Windows 2012 R2 Message-ID: <1487289828.27.0.409999068421.issue29583@psf.upfronthosting.co.za> New submission from Lane Campbell: When trying to install Python 3.6 using the "python-3.6.0-amd64.exe" installer on Windows 2012 R2 I encounter a failure. I'm flagging the options in the installer for: Customize Installation Add Python 3.6 to PATH Leaving all Optional Features selected Under Advanced Options I'm checking "Install for all users" and letting Python's installer select "Precompile standard library". This is what the installer outputs when it fails: http://pastebin.com/XUzVJ1Y5 I've tried to download KB2999226 & KB3118401 manually but they say they aren't for my version of Windows. I believe that the Python installer is detecting my version of Windows is 8.1 and isn't installing because of the Windows dependencies also fail since they are for version 8.1 (or at least appear to be). ---------- components: Windows messages: 287973 nosy: Lane Campbell, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python 3.6 won't install on Windows 2012 R2 versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 16 20:55:48 2017 From: report at bugs.python.org (Yaowei Zhang) Date: Fri, 17 Feb 2017 01:55:48 +0000 Subject: [New-bugs-announce] [issue29584] 2D list with Bugs when defined by using Multiplication Message-ID: <1487296548.29.0.763683149264.issue29584@psf.upfronthosting.co.za> Changes by Yaowei Zhang : ---------- components: Library (Lib) nosy: Yaowei Zhang priority: normal severity: normal status: open title: 2D list with Bugs when defined by using Multiplication versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 04:57:03 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 17 Feb 2017 09:57:03 +0000 Subject: [New-bugs-announce] [issue29585] site.py imports relatively large `sysconfig` module. Message-ID: <1487325423.07.0.0763065668443.issue29585@psf.upfronthosting.co.za> New submission from INADA Naoki: site.py uses sysconfig (and sysconfigdata, _osx_support) module for user-site package. But sysconfig module is not so lightweight, and very rarely used. Actually speaking, only tests and distutils uses sysconfig in stdlibs. And it takes about 7% of startup time, only for searching user-site path. I tried to port minimal subset of sysconfig into site.py (GH-136). But 'PYTHONFRAMEWORK' is only in sysconfigdata. So I couldn't get rid sysconfig dependency completely. How can I do to solve this? a) Drop "osx_framework_user" (`~/Library/Python/3.7/`) support completely. b) Add "sys._osx_framework" attribute c) Create minimal sysconfigdata only for site.py d) anything else? ---------- components: Library (Lib) messages: 287981 nosy: inada.naoki priority: normal pull_requests: 101 severity: normal status: open title: site.py imports relatively large `sysconfig` module. type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 05:48:03 2017 From: report at bugs.python.org (Adrian Chan) Date: Fri, 17 Feb 2017 10:48:03 +0000 Subject: [New-bugs-announce] [issue29586] Cannot run pip in fresh install of py 3.5.3 Message-ID: <1487328483.09.0.366256272135.issue29586@psf.upfronthosting.co.za> New submission from Adrian Chan: I uninstalled python 2.7 and 3.4, then performed a fresh install of 3.5.3. Running pip with `python -m pip` as per https://docs.python.org/3.5/installing gives the following error: C:\Python\Python35-32\python.exe: No module named pip.__main__; 'pip' is a package and cannot be directly executed Installation details: * win 7 64 bit. * python 3.5.3 32 bit. * chose options for pip, tcl/tk/idle, test suite, py launcher, shortcuts, add to env, precompile std lib. * installed to non-standard directory. ---------- assignee: docs at python components: Documentation, Installation, Windows messages: 287986 nosy: Adrian Chan, docs at python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Cannot run pip in fresh install of py 3.5.3 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 06:01:49 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Fri, 17 Feb 2017 11:01:49 +0000 Subject: [New-bugs-announce] [issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad Message-ID: <1487329309.81.0.182915384821.issue29587@psf.upfronthosting.co.za> New submission from Nathaniel Smith: Example 1: ----------- def f(): try: raise KeyError except Exception: yield gen = f() gen.send(None) gen.throw(ValueError) --------- Output: Traceback (most recent call last): File "", line 1, in File "", line 5, in f ValueError Expected output: Something involving the string "During handling of the above exception, another exception occurred", and a traceback for the original KeyError. Example 2: ----------- import sys def f(): try: raise KeyError except Exception: print(sys.exc_info()) try: yield except Exception: pass print(sys.exc_info()) raise gen = f() gen.send(None) gen.throw(ValueError) ----------- Output: (, KeyError(), ) (None, None, None) Traceback (most recent call last): File "/tmp/foo.py", line 17, in gen.throw(ValueError) File "/tmp/foo.py", line 13, in f raise RuntimeError: No active exception to reraise Expected output: certainly not that :-) This seems to happen because normally, generators save the current exc_info when yielding, and then restore it when re-entered. But, if we re-enter through 'throw' (throwflag is true), this is disabled: https://github.com/python/cpython/blob/b2ee40ed9c9041dcff9c898aa19aacf9ec60308a/Python/ceval.c#L1027 This check seems to have been added in ae5f2f4a39e6a3f4c45e9dc95bd4e1fe5dfb60f2 as a fix for: https://bugs.python.org/issue7173 which had to do with a nasty situation involving a generator object that was part of a reference cycle: the gc sometimes would free the objects stored in the generator's saved exc_info, and then try to clean up the generator by throwing in a GeneratorExit. AFAICT this situation shouldn't be possible anymore thanks to PEP 442, which makes it so that finalizers are run before any part of the cycle is freed. And in any case it certainly doesn't justify breaking code like the examples above. (Note: the examples use generators for simplicity, but of course the way I noticed this was that I had some async/await code where exceptions were mysteriously disappearing instead of showing up in __context__ and couldn't figure out why. It's likely that more people will run into this in the future as async/await becomes more widely used. As a workaround for now I'll probably modify my coroutine runner so that it never uses 'throw'.) ---------- messages: 287987 nosy: njs priority: normal severity: normal status: open title: Generator/coroutine 'throw' discards exc_info state, which is bad versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 06:35:23 2017 From: report at bugs.python.org (Jeroen Demeyer) Date: Fri, 17 Feb 2017 11:35:23 +0000 Subject: [New-bugs-announce] [issue29588] importing ssl can fail with NameError: name 'PROTOCOL_TLS' is not defined Message-ID: <1487331323.42.0.794986300226.issue29588@psf.upfronthosting.co.za> New submission from Jeroen Demeyer: This is a regression introduced in Python 2.7.13: Importing the ssl module can fail with >>> import ssl Traceback (most recent call last): File "", line 1, in File "/Users/jdemeyer/sage/local/lib/python/ssl.py", line 133, in PROTOCOL_SSLv23 = PROTOCOL_TLS NameError: name 'PROTOCOL_TLS' is not defined While getting an ImportError from the ssl module is expected if SSL is not available (httplib for example handles that fine), a NameError is not. ---------- assignee: christian.heimes components: SSL messages: 287989 nosy: christian.heimes, jdemeyer priority: normal severity: normal status: open title: importing ssl can fail with NameError: name 'PROTOCOL_TLS' is not defined versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 08:23:21 2017 From: report at bugs.python.org (Dima Zhukov) Date: Fri, 17 Feb 2017 13:23:21 +0000 Subject: [New-bugs-announce] [issue29589] test_asyncio & test_multiprocessing_forkserver failed Message-ID: <1487337801.01.0.342106615288.issue29589@psf.upfronthosting.co.za> New submission from Dima Zhukov: Hi, i'm new to Python. Just have downloded source code and tried to install it, but "make test" failed 2 test: test_asyncio and test_multiprocessing_forkserver. How bad is it and what should i do? Logs attached ---------- components: Build files: tests.output messages: 288005 nosy: Dima Zhukov priority: normal severity: normal status: open title: test_asyncio & test_multiprocessing_forkserver failed type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46643/tests.output _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 09:23:48 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Fri, 17 Feb 2017 14:23:48 +0000 Subject: [New-bugs-announce] [issue29590] Incorrect stack traces when re-entering a generator/coroutine stack via .throw() Message-ID: <1487341428.62.0.272190755105.issue29590@psf.upfronthosting.co.za> New submission from Nathaniel Smith: The attached script sets up a stack of generators calling each other via 'yield from': f yields from g yield from h. Then the generator at the bottom of the stack yields. Before they yield, sys._getframe shows the expected stack (or if you put in traceback.print_stack() you get the same thing). After they yield, it depends: if the generator is resumed via 'gen.send(None)', then the stack looks sensible. But if the generator is resumed via 'gen.throw(...)', then the stack is weird: Objects/genobject.c:_gen_throw implements 'yield from' in an weird manual way, where it first directly resumes the innermost generator frame, and then propagates any result to the next generator frame, etc. So the output I get from the sample script is: ~$ python3.6 weird-throw-stack.py -- f before yielding -- f -- g before yielding -- g f -- h before yielding -- h g f -- h after yielding -- h -- g after yielding -- g -- f after yielding -- f This causes problems for stack-based profiling (https://github.com/vmprof/vmprof-python/issues/117), debuggers, and other tools that need to introspect the stack. ---------- files: weird-throw-stack.py messages: 288010 nosy: njs priority: normal severity: normal status: open title: Incorrect stack traces when re-entering a generator/coroutine stack via .throw() versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46644/weird-throw-stack.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 10:39:39 2017 From: report at bugs.python.org (Natanael Copa) Date: Fri, 17 Feb 2017 15:39:39 +0000 Subject: [New-bugs-announce] [issue29591] Various security vulnerabilities in bundled expat Message-ID: <1487345979.72.0.358826213221.issue29591@psf.upfronthosting.co.za> New submission from Natanael Copa: cpython bundles expat in Modules/expat/ and needs to be updated to expat-2.2.0 to fix various security vulnerabilities. 21 June 2016, Expat 2.2.0 released. Release 2.2.0 includes security & other bug fixes. Security fixes CVE-2016-0718 (issue 537) Fix crash on malformed input CVE-2016-4472 Improve insufficient fix to CVE-2015-1283 / CVE-2015-2716 introduced with Expat 2.1.1 CVE-2016-5300 (issue 499) Use more entropy for hash initialization than the original fix to CVE-2012-0876 CVE-2012-6702 (issue 519) Resolve troublesome internal call to srand that was introduced with Expat 2.1.0 when addressing CVE-2012-0876 (issue 496) Fix should be applied to all maintained python branches. ---------- messages: 288014 nosy: Natanael Copa priority: normal severity: normal status: open title: Various security vulnerabilities in bundled expat type: security versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 11:19:42 2017 From: report at bugs.python.org (INADA Naoki) Date: Fri, 17 Feb 2017 16:19:42 +0000 Subject: [New-bugs-announce] [issue29592] abs_paths() in site.py is slow Message-ID: <1487348382.21.0.191353478088.issue29592@psf.upfronthosting.co.za> New submission from INADA Naoki: abs_paths() is the another most slow parts of site module. We can speedup it if we have C implementation of os.path.abspath() or abs_paths(). But before trying it, is abs_paths() really needed for now? It only rewrite `__file__` and `__cached__` of modules imported before site is imported. What is difference between modules loaded befere / after site module? Here is profile output. sysconfig dependency is removed by #29585 patch, and pstat is modified to show time in ms instead of sec. Ordered by: cumulative time ncalls tottime percall cumtime percall filename:lineno(function) 3/1 0.004 0.001 2.525 2.525 {built-in method builtins.exec} 1 0.003 0.003 2.524 2.524 x.py:1() 1 0.010 0.010 1.806 1.806 site.py:555(main) 4/3 0.022 0.005 1.179 0.393 :958(_find_and_load) 4/3 0.017 0.004 1.110 0.370 :931(_find_and_load_unlocked) 1 0.195 0.195 0.928 0.928 site.py:99(abs_paths) 108 0.098 0.001 0.776 0.007 posixpath.py:367(abspath) 4 0.035 0.009 0.647 0.162 :861(_find_spec) 4 0.005 0.001 0.589 0.147 :1150(find_spec) 4 0.043 0.011 0.584 0.146 :1118(_get_spec) 2/1 0.012 0.006 0.557 0.557 :641(_load_unlocked) 2/1 0.006 0.003 0.511 0.511 :673(exec_module) 108 0.461 0.004 0.493 0.005 posixpath.py:329(normpath) 16 0.150 0.009 0.453 0.028 :1234(find_spec) ---------- components: Library (Lib) messages: 288019 nosy: inada.naoki priority: normal severity: normal status: open title: abs_paths() in site.py is slow type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 12:06:57 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Fri, 17 Feb 2017 17:06:57 +0000 Subject: [New-bugs-announce] [issue29593] Improve UnboundLocalError message for deleted names Message-ID: <1487351217.08.0.939746599909.issue29593@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: Raymond Hettinger reported during PyCon Canada 2016 Keynote (~20m30 sec) that unbound local error message was inaccurate, it state that : > local variable 'xxx' referenced before assignment Though it can be assigned and deleted. for a toy example: def foo(): x = 1 del x print(x) foo() Do the same for free variable. def multiplier(n): def multiply(x): return x * n del n return multiply The error message can be improved by adding "or got deleted". ---------- messages: 288023 nosy: mbussonn priority: normal pull_requests: 102 severity: normal status: open title: Improve UnboundLocalError message for deleted names type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 12:59:32 2017 From: report at bugs.python.org (Marc Guetg) Date: Fri, 17 Feb 2017 17:59:32 +0000 Subject: [New-bugs-announce] [issue29594] implement __or__ in enum.auto Message-ID: <1487354372.81.0.144124774938.issue29594@psf.upfronthosting.co.za> New submission from Marc Guetg: At the moment it is only possible to combine flags that already exist: from enum import * class Foo(Flag): A = auto() # 1 B = auto() # 2 AB = A | B # 3 (1 | 2) AC = auto() | A # Fails, but should be 5 (1 | 4) ABD = auto() | A | B # Just taking it one step further to make a point, 11 (1 | 2 | 8) It would be nice to have this for cases when C only makes sense in combination with A but not on its own. A solution to achieve this one would need to change two things in ~/cpython/Lib/enum.py First extend class auto by: class auto: """ Instances are replaced with an appropriate value in Enum class suites. """ value = _auto_null or_value = 0 def __or__(self, other): """ Postpone the real or operation until value creation in _EnumDict """ self.or_value |= other return self And second change one line in _EnumDict: value = value.value changes to: value = value.value | value.or_value Some simple tests show the expected results: print(repr(Foo.A)) # A - 1 print(repr(Foo.B)) # B - 2 print(repr(Foo.AB)) # AB - 3 print(repr(Foo.AC)) # AC - 5 print(repr(Foo.A | Foo.AC)) # AC - 5 print(repr(Foo.A & Foo.AC)) # A - 1 print(repr(Foo.ABD)) # ABD - 11 Would it make sense to enhance python enums with that functionality? ---------- components: Library (Lib) files: test.py messages: 288029 nosy: magu priority: normal severity: normal status: open title: implement __or__ in enum.auto type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46646/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 17:10:23 2017 From: report at bugs.python.org (prayerslayer) Date: Fri, 17 Feb 2017 22:10:23 +0000 Subject: [New-bugs-announce] [issue29595] Expose max_queue_size in ThreadPoolExecutor Message-ID: <1487369423.42.0.265838648983.issue29595@psf.upfronthosting.co.za> New submission from prayerslayer: Hi! I think the ThreadPoolExecutor should allow to set the maximum size of the underlying queue. The situation I ran into recently was that I used ThreadPoolExecutor to parallelize AWS API calls; I had to move data from one S3 bucket to another (~150M objects). Contrary to what I expected the maximum size of the underlying queue doesn't have a non-zero value by default. Thus my process ended up consuming gigabytes of memory, because it put more items into the queue than the threads were able to work off: The queue just kept growing. (It ran on K8s and the pod was rightfully killed eventually.) Of course there ways to work around this. One could use more threads, to some extent. Or you could use your own queue with a defined maximum size. But I think it's more work for users of Python than necessary. ---------- messages: 288043 nosy: prayerslayer priority: normal pull_requests: 104 severity: normal status: open title: Expose max_queue_size in ThreadPoolExecutor type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 17 20:12:12 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Sat, 18 Feb 2017 01:12:12 +0000 Subject: [New-bugs-announce] [issue29596] Unfinished sentense in howto/clinic.rst Message-ID: <1487380332.64.0.682733186171.issue29596@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: Around line 1400 of Doc/howto/clinic.rst ``two-pass`` A buffer like ``buffer``. However, a two-pass buffer can only be written once, and it prints out all text sent to it during all of processing, even from Clinic blocks *after* the I've rarely be kept in such suspense ! Unless it's a reference to Monty Python's "The Man Who Finishes Other People's Sentences". In which case, I must say it's ---------- assignee: docs at python components: Documentation messages: 288048 nosy: docs at python, mbussonn priority: normal severity: normal status: open title: Unfinished sentense in howto/clinic.rst versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 18 15:31:11 2017 From: report at bugs.python.org (Max) Date: Sat, 18 Feb 2017 20:31:11 +0000 Subject: [New-bugs-announce] [issue29597] __new__ / __init__ calls during unpickling not documented correctly Message-ID: <1487449871.91.0.908560924036.issue29597@psf.upfronthosting.co.za> New submission from Max: According to the [docs](https://docs.python.org/3/library/pickle.html#pickling-class-instances): > Note: At unpickling time, some methods like `__getattr__()`, `__getattribute__()`, or `__setattr__()` may be called upon the instance. In case those methods rely on some internal invariant being true, the type should implement `__getnewargs__()` or `__getnewargs_ex__()` to establish such an invariant; otherwise, neither `__new__()` nor `__init__()` will be called. It seems, however, that this note is incorrect. First, `__new__` is called even if `__getnewargs__` isn't implemented. Second, `__init__` is not called even if it is (while the note didn't say that `__init__` would be called when `__getnewargs__` is defined, the wording does seem to imply it). class A: def __new__(cls, *args): print('__new__ called with', args) return object.__new__(cls) def __init__(self, *args): print('__init__ called with', args) self.args = args def __getnewargs__(self): print('called') return () a = A(1) s = pickle.dumps(a) a = pickle.loads(s) # __new__ called, not __init__ delattr(A, '__getnewargs__') a = A(1) s = pickle.dumps(a) a = pickle.loads(s) # __new__ called, not __init__ ---------- assignee: docs at python components: Documentation messages: 288088 nosy: docs at python, max priority: normal severity: normal status: open title: __new__ / __init__ calls during unpickling not documented correctly versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 04:49:40 2017 From: report at bugs.python.org (Artem Muterko) Date: Sun, 19 Feb 2017 09:49:40 +0000 Subject: [New-bugs-announce] [issue29598] Write unit tests for pdb module Message-ID: <1487497780.63.0.173110624211.issue29598@psf.upfronthosting.co.za> Changes by Artem Muterko : ---------- components: Tests nosy: Artem Muterko priority: normal severity: normal status: open title: Write unit tests for pdb module versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 06:37:36 2017 From: report at bugs.python.org (Sanyam Khurana) Date: Sun, 19 Feb 2017 11:37:36 +0000 Subject: [New-bugs-announce] [issue29599] Github organization link is secret and not accessible from core-dev guide Message-ID: <1487504256.78.0.675328219638.issue29599@psf.upfronthosting.co.za> New submission from Sanyam Khurana: On visiting link: https://docs.python.org/devguide/coredev.html#github The first sentence is "You will be added to the Python core team on GitHub." The ``Python core team`` refers to a link to Github which is not accessible to anyone except for those who are part of the organization. I'd like to suggest to either remove the link from the documentation or make the team visible to public. ---------- assignee: docs at python components: Documentation messages: 288131 nosy: CuriousLearner, docs at python, ncoghlan priority: normal severity: normal status: open title: Github organization link is secret and not accessible from core-dev guide type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 08:44:49 2017 From: report at bugs.python.org (Nathaniel Smith) Date: Sun, 19 Feb 2017 13:44:49 +0000 Subject: [New-bugs-announce] [issue29600] Returning an exception object from a coroutine triggers implicit exception chaining?!? Message-ID: <1487511889.54.0.248268466732.issue29600@psf.upfronthosting.co.za> New submission from Nathaniel Smith: The following code prints "KeyError()", which is obviously wrong and rather baffling. Just passing an exception object around *as an object* should not trigger implicit exception chaining! If you replace the async functions with regular functions then it prints "None", as expected. Checked on 3.5, 3.6, and more-or-less current master -- bug is present in all 3. ------------ async def f(): return ValueError() async def g(): try: raise KeyError except: value_error = await f() print(repr(value_error.__context__)) try: g().send(None) except StopIteration: pass ---------- components: Interpreter Core messages: 288133 nosy: njs priority: normal severity: normal status: open title: Returning an exception object from a coroutine triggers implicit exception chaining?!? versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 12:08:14 2017 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 19 Feb 2017 17:08:14 +0000 Subject: [New-bugs-announce] [issue29601] Need reST markup for enum types Message-ID: <1487524094.89.0.393871634605.issue29601@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: Over in https://github.com/python/cpython/pull/138 I noticed that we don't currently have markup for enum types. While class:: is technically still correct, it's not helpful because the html documentation should render this as `Enum SafeUUID` not `class SafeUUID`. ---------- assignee: docs at python components: Documentation messages: 288147 nosy: barry, berker.peksag, docs at python priority: normal severity: normal status: open title: Need reST markup for enum types versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 19 19:49:52 2017 From: report at bugs.python.org (Tom Krauss) Date: Mon, 20 Feb 2017 00:49:52 +0000 Subject: [New-bugs-announce] [issue29602] complex() on object with __complex__ function loses sign of zero imaginary part Message-ID: <1487551792.12.0.674027934311.issue29602@psf.upfronthosting.co.za> New submission from Tom Krauss: Consider the following simple class that provides a "__complex__" method. class C(object): def __init__(self, x): self.x = x def __complex__(self): return self.x x=C(-0j) PYTHON 2.7.13 >>> x.x -0j >>> complex(x) 0j PYTHON 3.6 >>> x.x (-0-0j) >>> complex(x) (-0+0j) ---------- messages: 288177 nosy: Tom Krauss priority: normal severity: normal status: open title: complex() on object with __complex__ function loses sign of zero imaginary part type: behavior versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 04:12:24 2017 From: report at bugs.python.org (slytomcat) Date: Mon, 20 Feb 2017 09:12:24 +0000 Subject: [New-bugs-announce] [issue29603] More informative Queue class: new method that returns number of unfinished tasks Message-ID: <1487581944.26.0.570957700938.issue29603@psf.upfronthosting.co.za> New submission from slytomcat: Class queue.Queue control the number of unfinished tasks via method task_done(). But it is only possible to get the information about all task done (via join() method). I'm sure that exposing the number of unfinished tasks (unfinished_tasks class variable) can be very useful in many situations when you need more control over the process. But it is not good idea to provide write access to this internal variable (as it controls internal queue class status). Better way - provide RO access via class method like qsize or empty. It can be look like this: def unfinished(self): return self.unfinished_tasks One example of this method usage: there is not optimal function _adjust_thread_count in concurrent.futures.ThreadPoolExecutor with following comment: # TODO(bquinlan): Should avoid creating new threads if there are more # idle threads than items in the work queue. It can be easily done with following condition: if self._work_queue.unfinished() <= len(self._threads): return ---------- components: Library (Lib) messages: 288189 nosy: rhettinger, slytomcat priority: normal severity: normal status: open title: More informative Queue class: new method that returns number of unfinished tasks versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 07:55:25 2017 From: report at bugs.python.org (Gianluca Rossi) Date: Mon, 20 Feb 2017 12:55:25 +0000 Subject: [New-bugs-announce] [issue29604] ImportError when importing the package `queue` Message-ID: <1487595325.27.0.987897101008.issue29604@psf.upfronthosting.co.za> New submission from Gianluca Rossi: In Python 3.5.2 importing *queue* raises an *ImportError*. ``` Python 3.5.2 (default, Jul 5 2016, 12:43:10) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import queue Traceback (most recent call last): File "", line 1, in File "/home/gianluca/git/python/asyncio/queue.py", line 1, in import asyncio File "/usr/lib/python3.5/asyncio/__init__.py", line 21, in from .base_events import * File "/usr/lib/python3.5/asyncio/base_events.py", line 18, in import concurrent.futures File "/usr/lib/python3.5/concurrent/futures/__init__.py", line 17, in from concurrent.futures.process import ProcessPoolExecutor File "/usr/lib/python3.5/concurrent/futures/process.py", line 52, in from queue import Full ImportError: cannot import name 'Full' ``` I'm not very familiar with the *asyncio* module since I've just recently started working with it. Please let me know if I can be of more help. ---------- components: asyncio messages: 288198 nosy: Gianluca Rossi, gvanrossum, yselivanov priority: normal severity: normal status: open title: ImportError when importing the package `queue` type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 08:13:49 2017 From: report at bugs.python.org (Marc Culler) Date: Mon, 20 Feb 2017 13:13:49 +0000 Subject: [New-bugs-announce] [issue29605] Python2.7-32 misreports architecture on macOS. Message-ID: <1487596429.09.0.910027328385.issue29605@psf.upfronthosting.co.za> New submission from Marc Culler: On macOS, the 32 bit python 2.7 reports its architecture as '64bit' in platform.architecture(). Note that the 32 bit Python versions 3.4, 3.5 and 3.6 all correctly report '32bit'. $ python-32 Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 12:39:47) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import platform >>> platform.architecture()[0] '64bit' >>> import sys >>> sys.maxsize > 2**32 False ---------- components: macOS messages: 288200 nosy: culler, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Python2.7-32 misreports architecture on macOS. versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 11:49:02 2017 From: report at bugs.python.org (ecbftw) Date: Mon, 20 Feb 2017 16:49:02 +0000 Subject: [New-bugs-announce] [issue29606] urllib FTP protocol stream injection Message-ID: <1487609342.46.0.653185585548.issue29606@psf.upfronthosting.co.za> New submission from ecbftw: Please see: http://blog.blindspotsecurity.com/2017/02/advisory-javapython-ftp-injections.html This was reported to security at python dot org, but as far as I can tell, they sat on it for a year. I don't think there is a proper way to encode newlines in CWD commands, according the FTP RFC. If that is the case, then I suggest throwing an exception on any URLs that contain one of '\r\n\0' or any other characters that the FTP protocol simply can't support. ---------- messages: 288219 nosy: ecbftw priority: normal severity: normal status: open title: urllib FTP protocol stream injection type: security versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 14:50:39 2017 From: report at bugs.python.org (Matthieu Dartiailh) Date: Mon, 20 Feb 2017 19:50:39 +0000 Subject: [New-bugs-announce] [issue29607] Broken stack_effect for CALL_FUNCTION_EX Message-ID: <1487620239.38.0.547704987013.issue29607@psf.upfronthosting.co.za> New submission from Matthieu Dartiailh: The computation of the stack_effect of the CALL_FUNCTION_EX does not reflect the use of the argument to the opcode. Currently stack_effect expect two flags (one on 0x01 and one on 0x02) corresponding to whether positional arguments and keyword arguments are being passed. However in the current implementation the argument of CALL_FUNCTION_EX is either 0 or 1 depending on the presence of keyword arguments. According to Serhiy Storchaka, the behavior of stack_effect is a left-over of the previous implementation and should be fixed. ---------- components: Interpreter Core messages: 288230 nosy: mdartiailh priority: normal severity: normal status: open title: Broken stack_effect for CALL_FUNCTION_EX type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 15:35:01 2017 From: report at bugs.python.org (Shyam Sunder) Date: Mon, 20 Feb 2017 20:35:01 +0000 Subject: [New-bugs-announce] [issue29608] pip_gui Message-ID: <1487622901.57.0.330485685393.issue29608@psf.upfronthosting.co.za> New submission from Shyam Sunder: I am not able see the text of the radio button clearly in the welcome page of search and install packages ---------- components: Tkinter files: Screenshot (70).png messages: 288238 nosy: Shyam Sunder, dstufft, lorenzogotuned, ncoghlan, ned.deily, r.david.murray, rhettinger, terry.reedy, upendra-k14 priority: normal pull_requests: 170 severity: normal status: open title: pip_gui type: performance versions: Python 2.7 Added file: http://bugs.python.org/file46655/Screenshot (70).png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 19:46:41 2017 From: report at bugs.python.org (pyguy) Date: Tue, 21 Feb 2017 00:46:41 +0000 Subject: [New-bugs-announce] [issue29609] Receiving messages from subprocess does not work on Mac OS X Message-ID: <1487638001.76.0.319134605715.issue29609@psf.upfronthosting.co.za> New submission from pyguy: When I use the subprocess module to run a another process, I expect to be able to read the STDOUT and STDERR of the other process. This is not possible on Mac OS X. The attached test program has been tested on Linux and Windows and does work as expected. It pauses at the process.stdout.readline() line of code every time on Mac OS X. ---------- components: macOS files: testwrapper.py messages: 288250 nosy: ned.deily, pyguy, ronaldoussoren priority: normal severity: normal status: open title: Receiving messages from subprocess does not work on Mac OS X type: behavior versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file46656/testwrapper.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 20 22:29:07 2017 From: report at bugs.python.org (Phus Lu) Date: Tue, 21 Feb 2017 03:29:07 +0000 Subject: [New-bugs-announce] [issue29610] ssl do_handshake fails on https-proxy (aka. https over https-proxy) Message-ID: <1487647747.15.0.370290912125.issue29610@psf.upfronthosting.co.za> New submission from Phus Lu: Background: I'm working on adding https-proxy[1] support to python-requests https://github.com/phuslu/requests_httpsproxy Issue: ssl module(python 2.7) counld establish ssl handshakes over a https-proxy Reproduce Steps: I setup a https-proxy in bwg.phus.lu:443 >>> import socket,ssl >>> sock = ssl.wrap_socket(socket.create_connection(('bwg.phus.lu', 443))) >>> sock.sendall('CONNECT httpbin.org:443 HTTP/1.0\r\n\r\n') 36 >>> sock.recv() 'HTTP/1.1 200 OK\r\n\r\n' >>> ssl.wrap_socket(sock) Traceback (most recent call last): File "", line 1, in ssl.wrap_socket(sock) File "/usr/lib/python2.7/ssl.py", line 943, in wrap_socket ciphers=ciphers) File "/usr/lib/python2.7/ssl.py", line 611, in __init__ self.do_handshake() File "/usr/lib/python2.7/ssl.py", line 840, in do_handshake self._sslobj.do_handshake() SSLError: [SSL: UNKNOWN_ALERT_TYPE] unknown alert type (_ssl.c:661) [1] https://www.chromium.org/developers/design-documents/secure-web-proxy ---------- messages: 288259 nosy: Phus Lu priority: normal severity: normal status: open title: ssl do_handshake fails on https-proxy (aka. https over https-proxy) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 04:50:54 2017 From: report at bugs.python.org (INADA Naoki) Date: Tue, 21 Feb 2017 09:50:54 +0000 Subject: [New-bugs-announce] [issue29611] TextIOWrapper's write_through option behave differently between C and pure Python implementation. Message-ID: <1487670654.12.0.413723829989.issue29611@psf.upfronthosting.co.za> New submission from INADA Naoki: In C implementation, write() calls underlaying flush() method when write_through=True. https://github.com/python/cpython/blob/3.6/Modules/_io/textio.c if (self->write_through) text_needflush = 1; if (self->line_buffering && (haslf || PyUnicode_FindChar(text, '\r', 0, PyUnicode_GET_LENGTH(text), 1) != -1)) needflush = 1; But pure Python implementation doesn't care write_through option at all. https://github.com/python/cpython/blob/3.6/Lib/_pyio.py self.buffer.write(b) if self._line_buffering and (haslf or "\r" in s): self.flush() When PyPy 3.5 is released, this difference may affects PyPy users. (I hadn't checked how PyPy provide io module.) ---------- components: IO messages: 288282 nosy: inada.naoki priority: normal severity: normal status: open title: TextIOWrapper's write_through option behave differently between C and pure Python implementation. type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 05:10:46 2017 From: report at bugs.python.org (Jussi Judin) Date: Tue, 21 Feb 2017 10:10:46 +0000 Subject: [New-bugs-announce] [issue29612] TarFile.extract() suffers from hard links inside tarball Message-ID: <1487671846.82.0.103027933595.issue29612@psf.upfronthosting.co.za> New submission from Jussi Judin: I managed to create a tarball that brought out quite nasty behavior with tarfile.TarFile.extract() and tarfile.TarFile.extractall() functions when there are hard links inside a tarball that point to themselves with a file that is included in the tarball. In Python 2.7 it leads to an exception and with Python 3.4-3.6 it extracts the same file from the tarball multiple times. First we create a tarball that causes this behavior: $ mkdir -p tardata/1/2/3/4/5/6/7/8/9 $ dd if=/dev/zero of=tardata/1/2/3/4/5/6/7/8/9/zeros.data bs=1000000 count=500 # tar by default adds all directories recursively multiple times to the archive, but duplicates are created as hard links: $ find tardata | xargs tar cvfz tardata.tar.gz Then let's extract the tarball with tarfile module Let following commands demonstrate what happens with the attached tartest.py file $ python2.7.13 tartest.py noskip tardata.tar.gz /tmp/tardata-python-2.7.13 ... tardata/1/2/3/4/5/6/7/8/9/zeros.data ... tardata/1/2/3/4/5/6/7/8/9/zeros.data Traceback (most recent call last): File "tartest.py", line 17, in unarchive(skip, archive, dest) File "tartest.py", line 12, in unarchive tar_fd.extract(info, dest) File "python/2.7.13/lib/python2.7/tarfile.py", line 2118, in extract self._extract_member(tarinfo, os.path.join(path, tarinfo.name)) File "python/2.7.13/lib/python2.7/tarfile.py", line 2202, in _extract_member self.makelink(tarinfo, targetpath) File "python/2.7.13/lib/python2.7/tarfile.py", line 2286, in makelink os.link(tarinfo._link_target, targetpath) OSError: [Errno 2] No such file or directory And with Python 3.6.0 (and earlier Python 3 series based Pythons that I have tested): $ time python3.6.0 tartest.py noskip tardata.tar.gz /tmp/tardata-python-3.6.0 ... tardata/1/2/3/4/5/6/7/8/9/zeros.data <-- this is extracted 11 times ... real 0m42.747s user 0m17.564s sys 0m6.144s If we then make the tarfile skip extraction of hard links that point to themselves: $ time python3.6.0 tartest.py skip tardata.tar.gz /tmp/tardata-python-3.6.0 ... tardata/1/2/3/4/5/6/7/8/9/zeros.data <-- this is extracted once ... Skipping tardata/1/2/3/4/5/6/7/8/9/zeros.data <-- skipped hard links 10 times ... real 0m2.688s user 0m1.816s sys 0m0.532s >From the used user CPU time it's obvious that there is happening a lot of unneeded decompression when we compare Python 3.6 results. If I use TarFile.extractall(), it behaves similarly as using TarFile.extract() individually on TarInfo objects. GNU tar seems to behave in such fashion that it skips over the extraction of the actual file data when it encounters this situation. ---------- components: Library (Lib) files: tartest.py messages: 288284 nosy: Jussi Judin priority: normal severity: normal status: open title: TarFile.extract() suffers from hard links inside tarball type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file46658/tartest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 05:54:31 2017 From: report at bugs.python.org (Akash Shende) Date: Tue, 21 Feb 2017 10:54:31 +0000 Subject: [New-bugs-announce] [issue29613] Support for SameSite Cookies Message-ID: <1487674471.93.0.248753692479.issue29613@psf.upfronthosting.co.za> New submission from Akash Shende: Right now Morsel dont accept cookie setting outside of reserved words defined in http/cookies.py ---------- components: Library (Lib) messages: 288287 nosy: akash0x53 priority: normal severity: normal status: open title: Support for SameSite Cookies type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 15:27:20 2017 From: report at bugs.python.org (Kirk Cieszkiewicz Jr.) Date: Tue, 21 Feb 2017 20:27:20 +0000 Subject: [New-bugs-announce] [issue29614] Additional implementation alternative to DictReader Message-ID: <1487708840.07.0.189630084412.issue29614@psf.upfronthosting.co.za> New submission from Kirk Cieszkiewicz Jr.: As discussed in the following: https://bugs.python.org/issue17537 https://mail.python.org/pipermail/python-ideas/2013-January/018844.html DictReader has a feature that will destroy data without warning if fieldnames had duplicate values (manual or automatic entries) Proposing renaming and re-implementation of DictReader class to instead return enumerate style output with a child class of DictReader to specifically return a dict object. ---------- components: Library (Lib) messages: 288318 nosy: Kirk Cieszkiewicz Jr. priority: normal severity: normal status: open title: Additional implementation alternative to DictReader type: enhancement versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 15:30:25 2017 From: report at bugs.python.org (Petr MOTEJLEK) Date: Tue, 21 Feb 2017 20:30:25 +0000 Subject: [New-bugs-announce] [issue29615] SimpleXMLRPCDispatcher._dispatch mangles tracebacks when invoking RPC calls through _dispatch Message-ID: <1487709025.37.0.198613157816.issue29615@psf.upfronthosting.co.za> New submission from Petr MOTEJLEK: Hello, We discovered that SimpleXMLRPCDispatcher mangles tracebacks printed from within the invoked RPC methods when an object that has _dispatch(method, params) defined has been registered with it Steps to reproduce - use https://docs.python.org/3.4/library/xmlrpc.server.html#xmlrpc.server.SimpleXMLRPCServer.register_instance and register within SimpleXMLRPCDispatcher an object with the _dispatch(method, params) method defined - invoke any RPC method that prints a traceback (perhaps raise an exception in it, catch it and use logging.exception to log it) --> the traceback will display a very strange looking KeyError (its value being the name of the invoked method) and then the actual exception that was fed into logging.exception The reason for this is that SimpleXMLRPCDispatcher._dispatch first attempts to acquire the function to invoke by reading from the functions registered with the dispatcher. When this attempt fails, KeyError is raised. During its handling different approaches are taken to acquire the function and for all but one when the function is acquired, handling of the KeyError ends and the function is called properly, outside of the except block However, in the case of objects that define the _dispatch(method, params) function, the _dispatch(method, params) function is called straight away, still within the except block handling the KeyError, and this leads to the mangled traceback This behavior is neither documented, nor expected (we believe) and thus the code should be changed Will submit a PR (incl. tests) for this later on ---------- components: Library (Lib) messages: 288319 nosy: petr at motejlek.net priority: normal severity: normal status: open title: SimpleXMLRPCDispatcher._dispatch mangles tracebacks when invoking RPC calls through _dispatch versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 21 18:27:42 2017 From: report at bugs.python.org (Juan) Date: Tue, 21 Feb 2017 23:27:42 +0000 Subject: [New-bugs-announce] [issue29616] input() after restarting causes bug Message-ID: <1487719662.64.0.83331129178.issue29616@psf.upfronthosting.co.za> New submission from Juan: This bug can be recreated by opening a file whose content is "input()" with IDLE, press F5 and the shell opens as expected. Without making the input in the shell stop, press F5 in the script again. In Python 3.5 IDLE only take input until another F5 (or Ctrl+F6) in the script. In Python 3.6 IDLE only take input until an Enter is pressed or another F5 (or Ctrl+F6) in the script. ---------- assignee: terry.reedy components: IDLE messages: 288324 nosy: Juan, terry.reedy priority: normal severity: normal status: open title: input() after restarting causes bug type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 00:37:49 2017 From: report at bugs.python.org (INADA Naoki) Date: Wed, 22 Feb 2017 05:37:49 +0000 Subject: [New-bugs-announce] [issue29617] Drop Python 3.4 support from asyncio Message-ID: <1487741869.94.0.0732011694463.issue29617@psf.upfronthosting.co.za> New submission from INADA Naoki: asyncio for Python 3.3 has not been released for two years. https://pypi.python.org/pypi/asyncio We have many code in asyncio for support Python 3.3. How about removing them? ---------- components: asyncio messages: 288332 nosy: gvanrossum, inada.naoki, yselivanov priority: normal severity: normal status: open title: Drop Python 3.4 support from asyncio versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 03:14:04 2017 From: report at bugs.python.org (Pauli Sundberg) Date: Wed, 22 Feb 2017 08:14:04 +0000 Subject: [New-bugs-announce] =?utf-8?q?=5Bissue29618=5D_Making_a_Tuple_or_?= =?utf-8?q?Dict_with_Callable=5B_=2E=2E=2E=2C_xxx=C2=A0=5D_gives_error?= Message-ID: <1487751244.2.0.980199684208.issue29618@psf.upfronthosting.co.za> New submission from Pauli Sundberg: Hi all. I tried asking this on IRC channel, but ended up with no answear. Simple example: from typing import Dict, Callable CmdFun = Callable[ ... , int ] CmdFull = Dict[ str, CmdFun ] Gives error: pauli at HPauli-U1604 ~ % python3 /tmp/silly.py Traceback (most recent call last): File "/tmp/silly.py", line 5, in CmdFull = Dict[ str, CmdFun ] File "/usr/lib/python3.5/typing.py", line 1025, in __getitem__ tvars = _type_vars(params) File "/usr/lib/python3.5/typing.py", line 284, in _type_vars _get_type_vars(types, tvars) File "/usr/lib/python3.5/typing.py", line 279, in _get_type_vars t._get_type_vars(tvars) File "/usr/lib/python3.5/typing.py", line 786, in _get_type_vars _get_type_vars(self.__args__, tvars) File "/usr/lib/python3.5/typing.py", line 277, in _get_type_vars for t in types: TypeError: 'ellipsis' object is not iterable The python intrepretter is the one shipped with ubuntu16.04 currently: Python 3.5.2 Based on the documentation i think this should be valid statement. The similar issue raises if the Dict is replaced with Tuple, but i did not try any other combinations. ---------- components: Library (Lib) messages: 288343 nosy: Pauli Sundberg priority: normal severity: normal status: open title: Making a Tuple or Dict with Callable[ ..., xxx?] gives error type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 07:24:02 2017 From: report at bugs.python.org (Mba) Date: Wed, 22 Feb 2017 12:24:02 +0000 Subject: [New-bugs-announce] [issue29619] st_ino (unsigned long long) is casted to long long in posixmodule.c:_pystat_fromstructstat Message-ID: <1487766242.34.0.703380697066.issue29619@psf.upfronthosting.co.za> New submission from Mba: ino_t is of type 'unsigned long' or 'unsigned long long'. Casting it to signed type means that negative values are incorrectly returned for large inodes. ---------- components: Library (Lib) messages: 288355 nosy: mba priority: normal severity: normal status: open title: st_ino (unsigned long long) is casted to long long in posixmodule.c:_pystat_fromstructstat type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 11:22:51 2017 From: report at bugs.python.org (kernc) Date: Wed, 22 Feb 2017 16:22:51 +0000 Subject: [New-bugs-announce] [issue29620] unittest.TestCase.assertWarns raises RuntimeEror if sys.modules changes size Message-ID: <1487780571.93.0.503711972358.issue29620@psf.upfronthosting.co.za> New submission from kernc: If any of the objects in sys.modules is a module-like object that performs some additional imports in its __getattribute__ (as appropriate) handler, the following simple unit test test case: import unittest import warnings ... # Ensure one of the imported modules is a module-like object as above class Case(unittest.TestCase): def test_assertWarns(self): with self.assertWarns(UserWarning): warnings.warn('Some warning') fails with: ====================================================================== ERROR: test_assertWarns (example.Case) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/example.py", line 9, in test_assertWarns with self.assertWarns(UserWarning): File "/usr/lib/python3.4/unittest/case.py", line 205, in __enter__ for v in sys.modules.values(): RuntimeError: dictionary changed size during iteration ---------------------------------------------------------------------- The problem is in the iteration over sys.modules in unittest.case._AssertWarnsContext.__enter__() and accessing every module's __warningregistry__ attribute. On this access, the module-like objects may perform arbitrary actions including importing of further modules which extends sys.modules. https://github.com/python/cpython/blob/16ea19fc6653ee4ec1be7cd0206073962119ac08/Lib/unittest/case.py#L226-L227 The simple proposed fix with no foreseen side-effects is to wrap sys.modules.values() call as a tuple(). ---------- components: Library (Lib) messages: 288370 nosy: kernc priority: normal severity: normal status: open title: unittest.TestCase.assertWarns raises RuntimeEror if sys.modules changes size type: behavior versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 11:35:21 2017 From: report at bugs.python.org (John Hagen) Date: Wed, 22 Feb 2017 16:35:21 +0000 Subject: [New-bugs-announce] [issue29621] telnetlib.Telnet.write gives confusing error message when a string is passed in Message-ID: <1487781321.4.0.45367640243.issue29621@psf.upfronthosting.co.za> New submission from John Hagen: I was recently helping someone learn Python 3 from Python 2 and they were confused by error resulting from the following easy-to-make mistake: import telnetlib tn = telnetlib.Telnet('localhost') tn.write('hello') Traceback (most recent call last): File "/Users/user/PycharmProjects/python-test/main.py", line 4, in tn.write('hello') File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/telnetlib.py", line 287, in write if IAC in buffer: TypeError: 'in ' requires string as left operand, not bytes What is confusing is that the solution is to pass in `bytes`, not a `str`, but the place where this manifests is in an `in` operator with the first argument as a `bytes` (telnetlib.IAC). Perhaps a simple isinstance(buffer, bytes) could be used to throw a `TypeError` or something a bit more helpful. It also doesn't help that for some reason Googling "python telnet" only seems to bring up the Python 2 docs link, rather than Python 3 or both. ---------- components: Library (Lib) messages: 288371 nosy: John Hagen priority: normal severity: normal status: open title: telnetlib.Telnet.write gives confusing error message when a string is passed in type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 11:48:32 2017 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Feb 2017 16:48:32 +0000 Subject: [New-bugs-announce] [issue29622] ast module doesn't support optional fields of Parser/Python.asdl Message-ID: <1487782112.74.0.332451655516.issue29622@psf.upfronthosting.co.za> New submission from STINNER Victor: The _ast.AST constructor requires a tuple with the same number of items than the fields list. Example with Raise: ASDL: Raise(expr? exc, expr? cause) >>> import _ast >>> _ast.Raise() <_ast.Raise object at 0x7fc2ca7dee90> >>> _ast.Raise(1) Traceback (most recent call last): File "", line 1, in TypeError: Raise constructor takes either 0 or 2 positional arguments >>> _ast.Raise(1, 2) <_ast.Raise object at 0x7fc2ca7def60> The cause field is optional in the ASDL, but required in the _ast module. A tradeoff would be to add the minimum and maximum number of fields to _ast.AST. This issue should prevent API breakage caused by the new docstring attribute added by issue #29463. ---------- messages: 288372 nosy: haypo, inada.naoki priority: normal severity: normal status: open title: ast module doesn't support optional fields of Parser/Python.asdl type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 13:48:55 2017 From: report at bugs.python.org (David Ellis) Date: Wed, 22 Feb 2017 18:48:55 +0000 Subject: [New-bugs-announce] [issue29623] configparser.ConfigParser.read() does not accept Pathlib path as a single argument. Message-ID: <1487789335.63.0.00643279339965.issue29623@psf.upfronthosting.co.za> New submission from David Ellis: Trying to use configparser.ConfigParser.read on a pathlib object results in a TypeError. If supplied in a list it works as expected. Repro: >>> import pathlib, configparser >>> configparser.ConfigParser().read(pathlib.Path('some.ini')) TypeError: 'PosixPath' object is not iterable The issue appears to be line 690 which checks for str before attempting to iterate and doesn't check for os.PathLike (or bytes?). This was actually mentioned as an example where pathlib did not work here: https://bugs.python.org/issue22570 ---------- components: Library (Lib) messages: 288378 nosy: David Ellis priority: normal severity: normal status: open title: configparser.ConfigParser.read() does not accept Pathlib path as a single argument. type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 14:20:28 2017 From: report at bugs.python.org (Steve Dower) Date: Wed, 22 Feb 2017 19:20:28 +0000 Subject: [New-bugs-announce] [issue29624] Python 3.5.3 x86 web installer cannot install launcher Message-ID: <1487791228.05.0.472749683063.issue29624@psf.upfronthosting.co.za> New submission from Steve Dower: For some reason, the install bootstrapper for 3.5.3 x86 embedded the wrong hash value for launcher.msi. As a result, it will fail to download the file and install will be aborted. The workaround is to deselect the launcher from being installed, and use the 64-bit installer to install the launcher. Or alternatively, install Python 3.6 to get the later version of the installer, which will then automatically skip it for the 3.5 installer. Python 3.6 is unaffected, so this may just have been a build glitch, but it needs investigation and testing so it doesn't happen again. (Adding a /layout test after uploading is an easy way to test this.) ---------- assignee: steve.dower components: Windows messages: 288379 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: critical severity: normal stage: test needed status: open title: Python 3.5.3 x86 web installer cannot install launcher type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 14:31:31 2017 From: report at bugs.python.org (Will Pittman) Date: Wed, 22 Feb 2017 19:31:31 +0000 Subject: [New-bugs-announce] [issue29625] colorsys.rgb_to_hsv always returns saturation as 0 (python2.7.13 only) Message-ID: <1487791891.85.0.764739478195.issue29625@psf.upfronthosting.co.za> New submission from Will Pittman: colorsys.rgb_to_hsv appears to be broken on python2.7.13 (on archlinux). Saturation is always reported as 0. ex: import colorsys rgb_to_hsv( 127, 116, 18 ) >>> (0.16666666666666666, 0, 127) ---------- messages: 288380 nosy: Will Pittman priority: normal severity: normal status: open title: colorsys.rgb_to_hsv always returns saturation as 0 (python2.7.13 only) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 18:00:55 2017 From: report at bugs.python.org (Falguniben Jhaveri) Date: Wed, 22 Feb 2017 23:00:55 +0000 Subject: [New-bugs-announce] [issue29626] Issue with spacing in argparse module while using help Message-ID: <1487804455.46.0.830935553244.issue29626@psf.upfronthosting.co.za> New submission from Falguniben Jhaveri: When I use argparse the optional arguments with character "-p" and "-s" has improper spacing while using help/usage command. Sample out put from argparse module: usage: cli node list [-h] [-p] [-o] Lists nodes in your current project. optional arguments: -h, --help show this help message and exit // extra space after p -p , --projectid -o, --org (For administrators only) Lists all the nodes in ---------- components: Library (Lib) messages: 288389 nosy: falu2010 priority: normal severity: normal status: open title: Issue with spacing in argparse module while using help versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 19:08:04 2017 From: report at bugs.python.org (David Ellis) Date: Thu, 23 Feb 2017 00:08:04 +0000 Subject: [New-bugs-announce] [issue29627] configparser.ConfigParser.read() has undocumented/unexpected behaviour when given a bytestring path. Message-ID: <1487808484.96.0.332923797285.issue29627@psf.upfronthosting.co.za> New submission from David Ellis: Related: https://github.com/python/cpython/pull/242 https://bugs.python.org/issue29623 In the discussion over my PR for bpo-29623 it became clear that bytestring paths were also unsupported and it was suggested that that should be a separate issue (currently the PR adds checks for both types). There is some possible odd behaviour as when given a bytestring path the method attempts to open the integer file descriptors for each character in the bytestring. This will most likely fail silently but if it does find an actual file descriptor it will attempt to read and then close the file. Example from the discussion on the PR: >>> import os >>> import configparser >>> k = os.open('/home/david/develop/cpython/Lib/test/cfgparser.1', os.O_RDONLY) >>> k 3 >>> c = configparser.ConfigParser() >>> c.read(b'\x03') [3] >>> list(c) ['DEFAULT', 'Foo Bar'] >>> os.close(k) # File has already been closed OSError: [Errno 9] Bad file descriptor Currently bytestrings do work correctly when provided as part of a list. ---------- components: Library (Lib) messages: 288394 nosy: David Ellis priority: normal severity: normal status: open title: configparser.ConfigParser.read() has undocumented/unexpected behaviour when given a bytestring path. type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Feb 22 22:55:46 2017 From: report at bugs.python.org (mesheb82) Date: Thu, 23 Feb 2017 03:55:46 +0000 Subject: [New-bugs-announce] [issue29628] struct objects can no longer be pickled Message-ID: <1487822146.07.0.247102500299.issue29628@psf.upfronthosting.co.za> New submission from mesheb82: When I run the following code on Windows/Linux for < Python 3.6, I have no problems. When I run in Python 3.6.0, I get the subsequent traceback. I checked the release notes and only saw the following struct module note related to half-floats: Issue #11734 from struct import Struct import copy this_fails = Struct(' copy.deepcopy(this_fails) File "F:\Anaconda\envs\py36\lib\copy.py", line 169, in deepcopy rv = reductor(4) TypeError: can't pickle Struct objects To be clear, I'm copying struct objects as part of a larger class. As I'm running many function calls where I create the same struct objects, saving the common struct objects allows me to get a factor of 2x speedup on my code. Deleting the saved struct objects at the end of file reading (and before the deepcopy takes place) fixes the problem. ---------- components: Windows messages: 288401 nosy: mesheb82, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: struct objects can no longer be pickled type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 00:55:34 2017 From: report at bugs.python.org (Madhavendra Sharma) Date: Thu, 23 Feb 2017 05:55:34 +0000 Subject: [New-bugs-announce] [issue29629] rgb_to_hls to colorsys.py Message-ID: <1487829334.94.0.604148512015.issue29629@psf.upfronthosting.co.za> New submission from Madhavendra Sharma: Calculations in rgb_to_hls at line number 67 in python version 2.7.3 for "h" the hue component are not correct according reference mentioned in the same source file "en.wikipedia.org/wiki/HSV_color_space". code snippet: if r == maxc: #h = (bc-gc) #current code h = (bc-gc)%6 # suggestion elif g == maxc: h = 2.0+rc-bc else: #h = 4.0+gc-rc #current code h = 4.0+rc-gc # suggestion #h = (h/6.0) % 1.0 not required # h = 60 *h # component should be multiplied by 60 but it depends on user ---------- messages: 288410 nosy: madhavendra.sharma priority: normal severity: normal status: open title: rgb_to_hls to colorsys.py type: behavior versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 03:14:27 2017 From: report at bugs.python.org (Francisco Demartino) Date: Thu, 23 Feb 2017 08:14:27 +0000 Subject: [New-bugs-announce] [issue29630] REPL tab-completion triggers code execution Message-ID: <1487837667.56.0.915081011558.issue29630@psf.upfronthosting.co.za> New submission from Francisco Demartino: On the REPL, when autocompleting with the TAB key, getattr is called, potentially triggering code execution. This took me by surprise. Until you press RETURN, it should be pretty safe to go around autocompleting with certainty that you won't run any code. But that might be just my opinion. What do you think? ---------- components: Interpreter Core files: wat.py messages: 288420 nosy: Francisco Demartino priority: normal severity: normal status: open title: REPL tab-completion triggers code execution versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46662/wat.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 05:01:40 2017 From: report at bugs.python.org (Karen) Date: Thu, 23 Feb 2017 10:01:40 +0000 Subject: [New-bugs-announce] =?utf-8?q?=5Bissue29631=5D_Error_=E2=80=9Cimp?= =?utf-8?q?ortlib=2Eh=2C_importlib=5Fexternal=2Eh_updated=2E_You_will_need?= =?utf-8?q?_to_rebuild_pythoncore_to_see_the_changes=2E=E2=80=9D_is_report?= =?utf-8?q?ed_when_build_Python_on_Winodws?= Message-ID: <1487844100.2.0.365499340143.issue29631@psf.upfronthosting.co.za> New submission from Karen: We use VS2015 to build Python(branch 3.6)on Windows. It failed with error "importlib.h, importlib_external.h updated. You will need to rebuild pythoncore to see the changes". This error is reported from Python 3.6 branch revision 3ab24bd. The detailed error log file is attached. Could you please help to take a look? Thank you so much! Here is repro steps: 1. git clone -b "3.6" -c core.autocrlf=true https://github.com/python/cpython.git D:\Python3\src 2. checkout the revision to 3ab24bd. 3. build -e -r -v ---------- components: Build files: Python3_x86_build.log messages: 288436 nosy: Karen priority: normal severity: normal status: open title: Error ?importlib.h, importlib_external.h updated. You will need to rebuild pythoncore to see the changes.? is reported when build Python on Winodws type: compile error versions: Python 3.6 Added file: http://bugs.python.org/file46664/Python3_x86_build.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 08:31:07 2017 From: report at bugs.python.org (Pedro) Date: Thu, 23 Feb 2017 13:31:07 +0000 Subject: [New-bugs-announce] [issue29632] argparse values for action in add_argument() should be flags instead of (or in addition to) strings Message-ID: <1487856667.94.0.619514979386.issue29632@psf.upfronthosting.co.za> New submission from Pedro: The possible values for action are currently: 'store' 'store_true' 'store_false' 'store_const' 'append' 'append_const' 'count' 'help' 'version' a subclass of argparse.Action The string values are evidently for backward compatibility with optparse. However, adding the ability to specify these options as flags would make argparse code more maintainable (e.g. IDEs are better at refactoring symbols than strings), bring it in line with other places where a module has built-in flags, like the regex module (re.MULTILINE, re.IGNORECASE, etc.), and expand the use of flags that already exist in argparse (e.g. argparse.SUPPRESS, argparse.REMAINDER). The string values need not be immediately deprecated, but can be made available as the preferred option for new development. See, for example, getName() and setName() in the threading module, which are documented as follows: "Old getter/setter API for name; use it directly as a property instead." A similar suggestion can be provided for argparse flags: "Old action values for backward compatibility; use the flags instead." ---------- messages: 288445 nosy: pgacv2 priority: normal severity: normal status: open title: argparse values for action in add_argument() should be flags instead of (or in addition to) strings type: enhancement versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 10:46:14 2017 From: report at bugs.python.org (aldehoff) Date: Thu, 23 Feb 2017 15:46:14 +0000 Subject: [New-bugs-announce] [issue29633] MSI installer does not pass values as SecureProperty from UI Message-ID: <1487864774.78.0.845992185721.issue29633@psf.upfronthosting.co.za> New submission from aldehoff: This is a revival of issue 1298962 (http://bugs.python.org/issue1298962) from 2009. I can reproduce the problem with an MSI created by cx_Freeze and bdist_msi on a Windows 7 64bit system in a company domain. Python is at version 3.6.0, cx_Freeze is at 5.0.1. I am a user with elevated user rights but not an admin. When installing the MSI, the files are always copied to C:\, whether I have changed the installation directory in GUI or stuck to the default path 'C:\Program Files (x86)\foo'. The program is executable and runs fine. The Uninstaller removes all files without a trace. Following the suggestions from issue 1298962 I have modified the MSI tables in Orca by adding a new Property entry with key 'SecureCustomProperties' and value 'TARGETDIR' fixes the MSI. It now installs into the desired directory. I can reproduce this on multiple builds. ---------- components: Installation, Windows messages: 288455 nosy: aldehoff, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: MSI installer does not pass values as SecureProperty from UI type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 11:39:23 2017 From: report at bugs.python.org (Louie Lu) Date: Thu, 23 Feb 2017 16:39:23 +0000 Subject: [New-bugs-announce] [issue29634] Reduce deque repeat execution when maxlen exist and size is not 1 Message-ID: <1487867963.03.0.590116533592.issue29634@psf.upfronthosting.co.za> New submission from Louie Lu: There is a XXX in v3.5.0 shows that need to dealing with deque maxlen setting case in deque_repeat. Although there have common case for deque size 1 with maxlen, other size of deque with maxlen still using for-loop to extend the deque, without any detection. Adding this fast break will reduce the execution speed when repeat deque with maxlen. --- $ cat tests.py from collections import deque for _ in range(10: d = deque(maxlen=100_000) d.insert(0, 0) d.insert(0, 10) d * 10_000_000 $ time ./python_with_patch tests.py $ time ./python tests.py ---------- components: Extension Modules messages: 288460 nosy: louielu priority: normal severity: normal status: open title: Reduce deque repeat execution when maxlen exist and size is not 1 type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 13:31:00 2017 From: report at bugs.python.org (Fabien Dubosson) Date: Thu, 23 Feb 2017 18:31:00 +0000 Subject: [New-bugs-announce] [issue29635] os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks Message-ID: <1487874660.16.0.665818668363.issue29635@psf.upfronthosting.co.za> Changes by Fabien Dubosson : ---------- components: Interpreter Core nosy: StreakyCobra priority: normal severity: normal status: open title: os.chdir() acts like `cd -P` by default, it should offer an option to not follow symlinks type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 15:05:56 2017 From: report at bugs.python.org (Daniel Himmelstein) Date: Thu, 23 Feb 2017 20:05:56 +0000 Subject: [New-bugs-announce] [issue29636] Specifying indent in the json.tool command Message-ID: <1487880356.98.0.87296874253.issue29636@psf.upfronthosting.co.za> New submission from Daniel Himmelstein: The utility of `python -m json.tool` would increase if users could specify the indent level. Example use case: newlines in a JSON document are important for readability and the ability to open in a text editor. However, if the file is large, you can save space by decreasing the indent level. I added an --indent argument to json.tool in https://github.com/python/cpython/pull/201. However, design discussion is required since indent can take an int, string, or None. In addition, a indent string is a tab, which is difficult to pass via a command line argument. Currently, I added the following function to convert the indent option to the indent parameter of json.dump: ``` def parse_indent(indent): """Parse the argparse indent argument.""" if indent == 'None': return None if indent == r'\t': return '\t' try: return int(indent) except ValueError: return indent ``` @inada.naoki mentioned the special casing is undesirable. I agree, but can't think of an alternative. Advice appreciated. ---------- components: IO messages: 288479 nosy: dhimmel, inada.naoki priority: normal pull_requests: 230 severity: normal status: open title: Specifying indent in the json.tool command type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 16:50:11 2017 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 23 Feb 2017 21:50:11 +0000 Subject: [New-bugs-announce] [issue29637] ast.get_docstring(): AttributeError: 'NoneType' object has no attribute 'expandtabs' Message-ID: <1487886611.55.0.299835659711.issue29637@psf.upfronthosting.co.za> New submission from Jakub Wilk: With git master (4c78c527d215c37472145152cb0e95f196cdddc9) I get this: >>> import ast >>> ast.get_docstring(ast.parse('')) Traceback (most recent call last): File "", line 1, in File "/home/jwilk/opt/lib/python3.7/ast.py", line 203, in get_docstring text = inspect.cleandoc(text) File "/home/jwilk/opt/lib/python3.7/inspect.py", line 590, in cleandoc lines = doc.expandtabs().split('\n') AttributeError: 'NoneType' object has no attribute 'expandtabs' ---------- messages: 288488 nosy: inada.naoki, jwilk priority: normal severity: normal status: open title: ast.get_docstring(): AttributeError: 'NoneType' object has no attribute 'expandtabs' type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 18:47:47 2017 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 23 Feb 2017 23:47:47 +0000 Subject: [New-bugs-announce] [issue29638] Spurious failures in test_collections in releak hunting mode after typing is imported Message-ID: <1487893667.97.0.185214523378.issue29638@psf.upfronthosting.co.za> New submission from Ivan Levkivskyi: This command: ./python -c 'import runpy, typing; runpy.run_module("test")' -R 5:5 test_collections Sometimes gives spurious failures like this: test_collections leaked [0, 0, 3, -3, 3] memory blocks, sum=3 I think this is because ABC caches of typing.ChainMap, typing.Counter, and typing.DefaultDict are not cleared by refleak.py/dash_R_cleanup (presumably because inspect.isabstract returns False on those) Adding a manual clean-up of these cashes to cleanup_cashes() fixes the "leak". ---------- assignee: levkivskyi components: Tests messages: 288495 nosy: gvanrossum, levkivskyi priority: normal severity: normal status: open title: Spurious failures in test_collections in releak hunting mode after typing is imported type: resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Feb 23 20:34:57 2017 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Feb 2017 01:34:57 +0000 Subject: [New-bugs-announce] [issue29639] test suite intentionally avoids referring to localhost, destroying abstraction away from IPv6 vs IPv4 Message-ID: <1487900097.24.0.236303974594.issue29639@psf.upfronthosting.co.za> New submission from Gregory P. Smith: I am working on fixing our test suite to run on IPv6 only hosts (which are becoming a reality). Many failures today occur because of hard coded 127.0.0.1 values. This is wrong. We should refer to "localhost" The "solution" to https://bugs.python.org/issue18792 moved us backwards towards hard coding IP version type specific addresses claiming that windows cannot handle resolving localhost reliably. On any windows system where that is the case we should declare the system broken and simply not run any networking related tests. ---------- components: Tests messages: 288498 nosy: gregory.p.smith priority: normal severity: normal status: open title: test suite intentionally avoids referring to localhost, destroying abstraction away from IPv6 vs IPv4 versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 04:03:58 2017 From: report at bugs.python.org (=?utf-8?b?SsOhbiBTdGFuxI1law==?=) Date: Fri, 24 Feb 2017 09:03:58 +0000 Subject: [New-bugs-announce] [issue29640] _PyThreadState_Init and fork race leads to inconsistent key list Message-ID: <1487927038.37.0.851881550844.issue29640@psf.upfronthosting.co.za> New submission from J?n Stan?ek: Following crash is sporadically observed in RHEL7 anaconda: (gdb) f 0 #0 PyThread_ReInitTLS () at /usr/src/debug/Python-2.7.5/Python/thread.c:411 411 if (p->id != id) { (gdb) list 406 keymutex = PyThread_allocate_lock(); 407 408 /* Delete all keys which do not match the current thread id */ 409 q = &keyhead; 410 while ((p = *q) != NULL) { 411 if (p->id != id) { 412 *q = p->next; 413 free((void *)p); 414 /* NB This does *not* free p->value! */ 415 } (gdb) p p $1 = (struct key *) 0x3333333333333333 (gdb) p keyhead $2 = (struct key *) 0x3333333333333333 key list is protected by keymutex (except for PyThread_ReInitTLS), but there doesn't seem to be any protection against concurrent fork(). What seems to happen is fork() at the moment when key list is not consistent. For example, if I initialize new key to 0xfe: static struct key *find_key(int key, void *value) // find_key with extra memset() ... p = (struct key *)malloc(sizeof(struct key)); memset(p, 0xfe, sizeof(struct key)); if (p != NULL) { p->id = id; p->key = key; p->value = value; p->next = keyhead; keyhead = p; } ... Looking at disassembly, compiler reordered last 2 writes: 0x00000000004fcb50 <+272>: callq 0x413d10 0x00000000004fcb55 <+277>: movabs $0xfefefefefefefefe,%rcx 0x00000000004fcb5f <+287>: test %rax,%rax 0x00000000004fcb62 <+290>: mov %rcx,(%rax) 0x00000000004fcb65 <+293>: mov %rcx,0x8(%rax) 0x00000000004fcb69 <+297>: mov %rcx,0x10(%rax) 0x00000000004fcb6d <+301>: mov %rcx,0x18(%rax) 0x00000000004fcb71 <+305>: je 0x4fcaff 0x00000000004fcb73 <+307>: mov 0x2f1e26(%rip),%rdx # 0x7ee9a0 0x00000000004fcb7a <+314>: mov 0x2f1dff(%rip),%rdi # 0x7ee980 0x00000000004fcb81 <+321>: xor %r14d,%r14d 0x00000000004fcb84 <+324>: mov %rbp,0x8(%rax) 0x00000000004fcb88 <+328>: mov %r12d,0x10(%rax) 0x00000000004fcb8c <+332>: mov %r13,0x18(%rax) 0x00000000004fcb90 <+336>: mov %rax,0x2f1e09(%rip) # 0x7ee9a0 0x00000000004fcb97 <+343>: mov %rdx,(%rax) Now consider what happens, when different threads call fork() in between these 2 writes: we updated keyhead, but keyhead->next has not been updated yet. Now when anaconda hangs, I get: (gdb) list 407 keymutex = PyThread_allocate_lock(); 408 409 /* Delete all keys which do not match the current thread id */ 410 q = &keyhead; 411 while ((p = *q) != NULL) { 412 if (p->id != id) { 413 *q = p->next; 414 free((void *)p); 415 /* NB This does *not* free p->value! */ 416 } (gdb) p p $1 = (struct key *) 0xfefefefefefefefe (gdb) p keyhead $2 = (struct key *) 0xfefefefefefefefe Here's how I think we get into this state: -------------------------> thread 1 # has GIL Thread.start _start_new_thread(self.__bootstrap, ()) PyThread_start_new_thread(t_bootstrap) # spawns thread 3 -------------------------> thread 2 ... # waiting for GIL -------------------------> thread 3 t_bootstrap _PyThreadState_Init # does not have GIL yet at this point _PyGILState_NoteThreadState PyThread_set_key_value(autoTLSkey, (void *)tstate) find_key # key list is temporarily not consistent # due to compiler reordering couple writes in find_key -------------------------> thread 1 continuing Thread.start self.__started.wait() Event.wait() self.__cond.wait Condition.wait() waiter = _allocate_lock() waiter.acquire() lock_PyThread_acquire_lock Py_BEGIN_ALLOW_THREADS PyEval_SaveThread PyThread_release_lock(interpreter_lock); -------------------------> thread 2 ... # acquired GIL os.fork() # forks inconsistent list -------------------------> child PyOS_AfterFork() PyThread_ReInitTLS() SIGSEGV Attached patch for python makes it easier to reproduce, by adding delays to couple places to make window key list is not consistent larger. ---------- components: Interpreter Core files: bz1268226_reproducer2.tar.gz messages: 288510 nosy: J?n Stan?ek priority: normal severity: normal status: open title: _PyThreadState_Init and fork race leads to inconsistent key list type: crash versions: Python 2.7 Added file: http://bugs.python.org/file46666/bz1268226_reproducer2.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 07:46:45 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Feb 2017 12:46:45 +0000 Subject: [New-bugs-announce] [issue29641] Missing _sysconfig_data when building+installating Python using PGO+LTO Message-ID: <1487940405.63.0.836671374296.issue29641@psf.upfronthosting.co.za> New submission from STINNER Victor: Hi, I compiled Python 3.7 using PGO+LTO with "make && make install", but it seems like it lacks the _sysconfigdata module. Moreover, I don't see any "Makefile" file in the installed directory, so the "~/installed/3.7/bin/python3 -S -m sysconfig --generate-posix-vars" command fails on trying to import _sysconfigdata_m_linux_x86_64-linux-gnu ... $ find /home/haypo/installed/3.7 -name "Makefile" Is it correct to use "make && make install" using PGO? cd ~/cpython make distclean ||: ./configure --enable-optimizations --with-lto --prefix=/home/haypo/installed/3.7 make clean make make install haypo at speed-python$ ~/installed/3.7/bin/python3 Failed to import the site module Traceback (most recent call last): File "/home/haypo/installed/3.7/lib/python3.7/site.py", line 544, in main() File "/home/haypo/installed/3.7/lib/python3.7/site.py", line 530, in main known_paths = addusersitepackages(known_paths) File "/home/haypo/installed/3.7/lib/python3.7/site.py", line 282, in addusersitepackages user_site = getusersitepackages() File "/home/haypo/installed/3.7/lib/python3.7/site.py", line 258, in getusersitepackages user_base = getuserbase() # this will also set USER_BASE File "/home/haypo/installed/3.7/lib/python3.7/site.py", line 248, in getuserbase USER_BASE = get_config_var('userbase') File "/home/haypo/installed/3.7/lib/python3.7/sysconfig.py", line 601, in get_config_var return get_config_vars().get(name) File "/home/haypo/installed/3.7/lib/python3.7/sysconfig.py", line 550, in get_config_vars _init_posix(_CONFIG_VARS) File "/home/haypo/installed/3.7/lib/python3.7/sysconfig.py", line 421, in _init_posix _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0) ModuleNotFoundError: No module named '_sysconfigdata_m_linux_x86_64-linux-gnu' ---------- components: Build messages: 288523 nosy: haypo priority: normal severity: normal status: open title: Missing _sysconfig_data when building+installating Python using PGO+LTO versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 11:48:45 2017 From: report at bugs.python.org (Andrei Fokau) Date: Fri, 24 Feb 2017 16:48:45 +0000 Subject: [New-bugs-announce] [issue29642] Why does unittest.TestLoader.discover still rely on existence of __init__.py files? Message-ID: <1487954925.89.0.910316575912.issue29642@psf.upfronthosting.co.za> New submission from Andrei Fokau: Hi, As far as I see, unittest.TestLoader doesn't search in PEP-420 packages, i.e. packages without __init__.py files. Is there some motivation behind this, or the loader was just not yet adapted for Implicit Namespace Packages? ---------- components: Tests messages: 288529 nosy: Andrei Fokau priority: normal severity: normal status: open title: Why does unittest.TestLoader.discover still rely on existence of __init__.py files? type: behavior versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Feb 24 18:20:10 2017 From: report at bugs.python.org (Alex Wang) Date: Fri, 24 Feb 2017 23:20:10 +0000 Subject: [New-bugs-announce] [issue29643] --enable-optimizations compiler flag has no effect Message-ID: <1487978410.86.0.66468070718.issue29643@psf.upfronthosting.co.za> New submission from Alex Wang: PR submitted here: https://github.com/python/cpython/pull/129 ---------- components: Build messages: 288535 nosy: awang priority: normal severity: normal status: open title: --enable-optimizations compiler flag has no effect type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 00:59:09 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Feb 2017 05:59:09 +0000 Subject: [New-bugs-announce] [issue29644] Importing webbrowser outputs a message on stderr Message-ID: <1488002349.82.0.416904492527.issue29644@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Importing webbrowser has a side effect. It outputs a message on stderr. >>> import webbrowser /usr/bin/xdg-settings: 1: /usr/bin/xdg-settings: kreadconfig5: not found This is a regression introduced in issue24241. ---------- components: Library (Lib) messages: 288542 nosy: daves, ncoghlan, serhiy.storchaka priority: normal severity: normal status: open title: Importing webbrowser outputs a message on stderr type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 04:26:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Feb 2017 09:26:58 +0000 Subject: [New-bugs-announce] [issue29645] webbrowser module import has heavy side effects Message-ID: <1488014818.45.0.347439137836.issue29645@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: `import webbrowser` has heavy side effects. It searches a number of executables. On X Window it also runs external program xdg-settings. Cold start: $ time ./python -c '' real 0m1.719s user 0m0.088s sys 0m0.036s $ time ./python -c 'import webbrowser' real 0m5.713s user 0m0.308s sys 0m0.196s Hot start: $ time ./python -c '' real 0m0.094s user 0m0.072s sys 0m0.020s $ time ./python -c 'import webbrowser' real 0m1.026s user 0m0.284s sys 0m0.100s ---------- components: Library (Lib) messages: 288551 nosy: serhiy.storchaka priority: normal severity: normal status: open title: webbrowser module import has heavy side effects type: performance versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 05:11:14 2017 From: report at bugs.python.org (ProgVal) Date: Sat, 25 Feb 2017 10:11:14 +0000 Subject: [New-bugs-announce] [issue29646] ast.parse parses string literals as docstrings Message-ID: <1488017474.82.0.510705451236.issue29646@psf.upfronthosting.co.za> New submission from ProgVal: Since commit cb41b2766de646435743b6af7dd152751b54e73f (Python 3.7a0), string literals are not parsed the same way. ast.parse("'test'").body used to be a list with one item containing 'test'; but now it is an empty list: Python 3.5.2+ (default, Dec 13 2016, 14:16:35) [GCC 6.2.1 20161124] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ast >>> print(ast.parse("'test'")) <_ast.Module object at 0x7fa37ae4c630> >>> print(ast.parse("'test'").body) [<_ast.Expr object at 0x7fa37ae4c630>] >>> print(ast.parse("'test'").docstring) Traceback (most recent call last): File "", line 1, in AttributeError: 'Module' object has no attribute 'docstring' Python 3.7.0a0 (default, Feb 24 2017, 21:38:30) [GCC 6.3.0 20170205] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ast >>> print(ast.parse("'test'")) <_ast.Module object at 0x7fe2aa415eb8> >>> print(ast.parse("'test'").body) [] >>> print(ast.parse("'test'").docstring) test ---------- components: Interpreter Core messages: 288553 nosy: Valentin.Lorentz, inada.naoki priority: normal severity: normal status: open title: ast.parse parses string literals as docstrings versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 05:44:46 2017 From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=) Date: Sat, 25 Feb 2017 10:44:46 +0000 Subject: [New-bugs-announce] [issue29647] Python 3.6.0 Message-ID: <1488019486.61.0.519104192043.issue29647@psf.upfronthosting.co.za> New submission from Bo?tjan Mejak: I managed to create an app that crashes the latest stable version of Python, that is 3.6.0 at the time of this writing. My application is written in Python using wxPython Phoenix 3rd-party GUI library/toolkit. I am running Windows 10 Home 64-bit version OS, the latest version of it, the Anniversary Edition with all its updates. How I did it? Well, I made an event in my GUI app where clicking the X button puts up a message dialog to the user, saying "Do you really wanna close this app?" and the "Yes" button destroys the whole object, thus exiting the application. But now the catch! I also made a taskbar icon which includes a menu item to also exit the application: same message dialog with Yes/No buttons. Let's crash this baby! If you click the X button and not choosing either "Yes" or "No" but instead have this message dialog wait and in the mean time you right-click the taskbar icon and choose the "Exit" menu item and choose "Yes". Then click another "Yes" of that waiting message dialog and BOOM! Voila, we have killed PYthon interpreter. Is that a bug in my code or does Python have a weakness? ---------- components: Interpreter Core messages: 288557 nosy: Pikec, gvanrossum priority: normal severity: normal status: open title: Python 3.6.0 type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 06:22:08 2017 From: report at bugs.python.org (Marco Buttu) Date: Sat, 25 Feb 2017 11:22:08 +0000 Subject: [New-bugs-announce] [issue29648] Missed reference to create_module() in versionadded (import.rst) Message-ID: <1488021728.97.0.531293750465.issue29648@psf.upfronthosting.co.za> New submission from Marco Buttu: In the first `versionadded` of the Loader section [1] of Doc/reference/import.rst, there is no reference to `create_module()`: .. versionadded:: 3.4 The create_module() method of loaders. It should be: .. versionadded:: 3.4 The :meth:`~importlib.abc.Loader.create_module` method of loaders. I will make a PR. [1] https://docs.python.org/3/reference/import.html#loaders ---------- messages: 288560 nosy: marco.buttu priority: normal severity: normal status: open title: Missed reference to create_module() in versionadded (import.rst) versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 08:53:04 2017 From: report at bugs.python.org (Louie Lu) Date: Sat, 25 Feb 2017 13:53:04 +0000 Subject: [New-bugs-announce] [issue29649] struct.pack_into check boundary error message didn't respect offset Message-ID: <1488030784.09.0.674246877605.issue29649@psf.upfronthosting.co.za> New submission from Louie Lu: For this situation, check boundary error message didn't correctly show out. >>> import struct >>> import ctypes >>> byte_list = ctypes.create_string_buffer(1) >>> struct.pack_into('b', byte_list, 5, 1) Traceback (most recent call last): File "", line 1, in struct.error: pack_into requires a buffer of at least 1 bytes Since offset is setting at 5, it should at least need `offset + soself->s_size` bytes to store it. ---------- components: Extension Modules messages: 288564 nosy: louielu priority: normal severity: normal status: open title: struct.pack_into check boundary error message didn't respect offset versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 11:46:46 2017 From: report at bugs.python.org (chrysn) Date: Sat, 25 Feb 2017 16:46:46 +0000 Subject: [New-bugs-announce] [issue29650] abstractmethod does not work when deriving from Exception Message-ID: <1488041206.17.0.0120524792135.issue29650@psf.upfronthosting.co.za> New submission from chrysn: The "TypeError: Can't instantiate abstract class C with abstract methods x" exception does not get raised when when the involved ABCMeta class is derived from an Exception. The attached file shows that a class without an implementation of an abstractmethod can get instanciated; replacing the derivation from Exception with a derivation from another class (say, A) makes the instanciation throw the proper TypeError. ---------- files: demo.py messages: 288571 nosy: chrysn priority: normal severity: normal status: open title: abstractmethod does not work when deriving from Exception type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46668/demo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 14:45:27 2017 From: report at bugs.python.org (Vasiliy Faronov) Date: Sat, 25 Feb 2017 19:45:27 +0000 Subject: [New-bugs-announce] [issue29651] Inconsistent/undocumented urlsplit/urlparse behavior on invalid inputs Message-ID: <1488051927.22.0.367579438822.issue29651@psf.upfronthosting.co.za> New submission from Vasiliy Faronov: There is a problem with the standard library's urlsplit and urlparse functions, in Python 2.7 (module urlparse) and 3.2+ (module urllib.parse). The documentation for these functions [1] does not explain how they behave when given an invalid URL. One could try invoking them manually and conclude that they tolerate anything thrown at them: >>> urlparse('http:////::\\\\!!::!!++///') ParseResult(scheme='http', netloc='', path='//::\\\\!!::!!++///', params='', query='', fragment='') >>> urlparse(os.urandom(32).decode('latin-1')) ParseResult(scheme='', netloc='', path='\x7f??1gd??6\x82', params='', query='', fragment='\n\xadJ\x18+fli\x9c?\x9ak*??\x02?F\x85?\x18') Without studying the source code, it is impossible to know that there is a very narrow class of inputs on which they raise ValueError [2]: >>> urlparse('http://[') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/urllib/parse.py", line 295, in urlparse splitresult = urlsplit(url, scheme, allow_fragments) File "/usr/lib/python3.5/urllib/parse.py", line 345, in urlsplit raise ValueError("Invalid IPv6 URL") ValueError: Invalid IPv6 URL This could be viewed as a documentation issue. But it could also be viewed as an implementation issue. Instead of raising ValueError on those square brackets, urlsplit could simply consider them *invalid* parts of an RFC 3986 reg-name, and lump them into netloc, as it already does with other *invalid* characters: >>> urlparse('http://\0\0??\n/') ParseResult(scheme='http', netloc='\x00\x00??\n', path='/', params='', query='', fragment='') Note that the raising behavior was introduced in Python 2.7/3.2. See also issue 8721 [3]. [1] https://docs.python.org/3/library/urllib.parse.html [2] https://github.com/python/cpython/blob/e32ec93/Lib/urllib/parse.py#L406-L408 [3] http://bugs.python.org/issue8721 ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 288577 nosy: docs at python, vfaronov priority: normal severity: normal status: open title: Inconsistent/undocumented urlsplit/urlparse behavior on invalid inputs type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 14:54:43 2017 From: report at bugs.python.org (Jim Fasarakis-Hilliard) Date: Sat, 25 Feb 2017 19:54:43 +0000 Subject: [New-bugs-announce] [issue29652] Fix evaluation order of keys/values in dict comprehensions Message-ID: <1488052483.04.0.021043093911.issue29652@psf.upfronthosting.co.za> New submission from Jim Fasarakis-Hilliard: Reported from [1] and similar to issue11205 Currently the evaluation order for keys and values in a dictionary comprehension follows that of assignments. The values get evaluated first and then the keys: def printer(v): print(v, end=' ') return v d = {printer(i): printer(j) for i, j in [(1, 2), (3, 4)]} # 2 1 4 3 This seems to conflict with the semantics as described in the Semantics section of PEP 274 [2] and according to my interpretation of the reference manual (I'd expect the evaluation to be similar to dict-displays). How should this be addressed? Fix the evaluation order or specify this edge case an "Implementation detail" in the reference manual? I already have a fix for this lying around (changes to `compiler_sync_comprehension_generator`, `compiler_sync_comprehension_generator` and a switch in `MAP_ADD`) and can make a pull request if required. I'm not sure if this is classified as a bug per-se so I only tagged Py3.7 for it. [1] http://stackoverflow.com/questions/42201932/order-of-operations-in-a-dictionary-comprehension [2] https://www.python.org/dev/peps/pep-0274/#semantics ---------- components: Interpreter Core messages: 288578 nosy: Jim Fasarakis-Hilliard priority: normal severity: normal status: open title: Fix evaluation order of keys/values in dict comprehensions type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 15:34:32 2017 From: report at bugs.python.org (assume_away) Date: Sat, 25 Feb 2017 20:34:32 +0000 Subject: [New-bugs-announce] [issue29653] IDLE - call tips show wrapper's argpsec instead of wrapped Message-ID: <1488054872.48.0.0975525232786.issue29653@psf.upfronthosting.co.za> New submission from assume_away: Many wrappers use the famous (*args, **kwargs) argspec, which is less than helpful for a function that uses some positional arguments and maybe a few keyword only arguments, ie (x, y, z=10). Other IDEs have the capability of showing the wrapped functions argspec in a calltip, so why shouldn't IDLE? ---------- assignee: terry.reedy components: IDLE files: calltips.py messages: 288580 nosy: assume_away, terry.reedy priority: normal severity: normal status: open title: IDLE - call tips show wrapper's argpsec instead of wrapped type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file46669/calltips.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 16:20:35 2017 From: report at bugs.python.org (Pierre Quentel) Date: Sat, 25 Feb 2017 21:20:35 +0000 Subject: [New-bugs-announce] [issue29654] SimpleHTTPRequestHandler should support browser cache Message-ID: <1488057635.77.0.128841709763.issue29654@psf.upfronthosting.co.za> New submission from Pierre Quentel: SimpleHTTPServer send a Last-Modified response header, but doesn't take into account the If-Modified-Since header if it was sent by the user agent. If a url matches a file and this file was not modified after the value of the If-Modified-Since header, the server should return HTTP status 304 (Not Modified). ---------- components: Library (Lib) messages: 288581 nosy: quentel priority: normal severity: normal status: open title: SimpleHTTPRequestHandler should support browser cache type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 16:26:53 2017 From: report at bugs.python.org (Peter Cawley) Date: Sat, 25 Feb 2017 21:26:53 +0000 Subject: [New-bugs-announce] [issue29655] Certain errors during IMPORT_STAR can leak a reference Message-ID: <1488058013.56.0.788869646449.issue29655@psf.upfronthosting.co.za> New submission from Peter Cawley: In the implementation of the IMPORT_STAR opcode, if the call to PyFrame_FastToLocalsWithError fails, or f_locals is NULL, then control flow jumps to the error handler without performing a decref on the "from" variable. As the "from" variable is initialised by POPping from the stack, the reference is leaked. ---------- components: Interpreter Core messages: 288582 nosy: Peter Cawley priority: normal severity: normal status: open title: Certain errors during IMPORT_STAR can leak a reference type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Feb 25 23:52:17 2017 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Feb 2017 04:52:17 +0000 Subject: [New-bugs-announce] [issue29656] Change "make patchcheck" to be branch aware? Message-ID: <1488084737.09.0.284465642742.issue29656@psf.upfronthosting.co.za> New submission from Nick Coghlan: With the switch to a PR based workflow, I'm finding the current incarnation of "make patchcheck" less helpful than it used to be, as it only checks uncommitted changes, rather than all changes relative to the base branch. Looking at Tools/scripts/patchcheck.py, it seems like it should be possible to use sys.version_info to calculate a suitable base branch ('master' if the release is alpha, '{major}.{minor}' otherwise), but things get a bit trickier from there: - the local branches may not be up to date if the PR branch is based directly on a remote branch, so we can't rely on those - figuring out which remote to use isn't immediately obvious, but we could probably go with an approach of using "upstream/{branch}" if an "upstream" remote is defined, and "origin/{branch}" otherwise - once we have a base branch to use, then `git diff --name-status {branch}` should give us the file list in a similar format to the current `git status --porcelain` I'll put together a PR for this approach. ---------- assignee: ncoghlan messages: 288588 nosy: brett.cannon, ncoghlan priority: normal severity: normal status: open title: Change "make patchcheck" to be branch aware? type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 03:52:24 2017 From: report at bugs.python.org (Wolfgang Rohdewald) Date: Sun, 26 Feb 2017 08:52:24 +0000 Subject: [New-bugs-announce] [issue29657] os.symlink: FileExistsError shows wrong message Message-ID: <1488099144.41.0.738429373533.issue29657@psf.upfronthosting.co.za> New submission from Wolfgang Rohdewald: execute the attached script. It should return FileExistsError: [Errno 17] File exists: 'a_link' -> 'a' but it returns FileExistsError: [Errno 17] File exists: 'a' -> 'a_link' ---------- components: Library (Lib) files: x.py messages: 288591 nosy: wrohdewald priority: normal severity: normal status: open title: os.symlink: FileExistsError shows wrong message versions: Python 3.5 Added file: http://bugs.python.org/file46671/x.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 08:48:30 2017 From: report at bugs.python.org (djstrong) Date: Sun, 26 Feb 2017 13:48:30 +0000 Subject: [New-bugs-announce] [issue29658] Process hangs (sometimes) Message-ID: <1488116910.28.0.662838065018.issue29658@psf.upfronthosting.co.za> New submission from djstrong: I have this code, which sometimes hangs (1 of 5 runs): # -*- coding: utf-8 -*- import sys import threading import multiprocessing mpl = multiprocessing.log_to_stderr() mpl.setLevel(1) class A(threading.Thread): def __init__(self): super(A, self).__init__() def run(self): print(self.name, 'RUN') for line in sys.stdin: #increases probability of hanging pass print(self.name, 'STOP') class B(multiprocessing.Process): def __init__(self): super(B, self).__init__() def run(self): print(self.name, 'RUN') a = A() a.start() b = B() b.start() print('B started', b, b.is_alive(), b.pid) print('A', a) a.join() b.join() print('FINISHED') I am running it on Ubuntu with command: echo "" | python3 time_test4.py Output is: Thread-1 RUN B started True 31439 A Thread-1 STOP ---------- messages: 288594 nosy: djstrong priority: normal severity: normal status: open title: Process hangs (sometimes) type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 19:57:24 2017 From: report at bugs.python.org (tyler) Date: Mon, 27 Feb 2017 00:57:24 +0000 Subject: [New-bugs-announce] [issue29659] Expose the `length` arg from shutil.copyfileobj for public use Message-ID: <1488157044.73.0.933925559387.issue29659@psf.upfronthosting.co.za> New submission from tyler: It would be handy to be able to pass the `length` default argument defined by `shutil.copyfileobj()` to other public functions througout the module. When copying very large files (1GB +), increasing the memory buffer can divide the copy time in half and currently the only way to accomplish this is by overriding the needed function(s) which call `shutil.copyfileobj()`. I propose a simple non-invasive change where the following functions will also expose the `length` kwarg and pass it downwards to `copyfileobj`: - copyfile - copy - copy2 ---------- messages: 288616 nosy: goodboy priority: normal severity: normal status: open title: Expose the `length` arg from shutil.copyfileobj for public use versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 20:21:39 2017 From: report at bugs.python.org (Matthias Bussonnier) Date: Mon, 27 Feb 2017 01:21:39 +0000 Subject: [New-bugs-announce] [issue29660] Document that print/format_exception ignore etype Message-ID: <1488158499.0.0.645448196253.issue29660@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: As far as I can tell, http://bugs.python.org/issue17911 made a couple of function in traceback ignore their first arguments (etype) and infer the type from the second one (evalue). (In git 6bc2c1e7 and 2f0441f0 respectively). At least print_exception and format_exception are affected. This likely affect http://bugs.python.org/issue26389 (who wish to expand same API to remove these parameters). And inconsistency with `format_exception_only` which does need `etype` should be checked. If etype is a deprecated parameter it should be noted, and should likely raise a DeprecationWarning as well when set. ---------- assignee: docs at python components: Documentation messages: 288617 nosy: docs at python, mbussonn priority: normal severity: normal status: open title: Document that print/format_exception ignore etype versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Feb 26 23:02:11 2017 From: report at bugs.python.org (Antony Lee) Date: Mon, 27 Feb 2017 04:02:11 +0000 Subject: [New-bugs-announce] [issue29661] Typo in the docstring of timeit.Timer.autorange Message-ID: <1488168131.96.0.70434953858.issue29661@psf.upfronthosting.co.za> New submission from Antony Lee: The docstring of timeit.Timer.autorange currently reads | Return the number of loops so that total time >= 0.2. | | Calls the timeit method with *number* set to successive powers of | ten (10, 100, 1000, ...) up to a maximum of one billion, until | the time taken is at least 0.2 second, or the maximum is reached. | Returns ``(number, time_taken)``. | | If *callback* is given and is not None, it will be called after | each trial with two arguments: ``callback(number, time_taken)``. Note the contradiction between the return values documented in the first and second paragraphs (the second one is correct). ---------- components: Library (Lib) messages: 288619 nosy: Antony.Lee priority: normal severity: normal status: open title: Typo in the docstring of timeit.Timer.autorange versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 00:08:33 2017 From: report at bugs.python.org (Xiang Zhang) Date: Mon, 27 Feb 2017 05:08:33 +0000 Subject: [New-bugs-announce] [issue29662] Fix wrong indentation of timeit.Timer's documenation Message-ID: <1488172113.69.0.408752605345.issue29662@psf.upfronthosting.co.za> Changes by Xiang Zhang : ---------- assignee: xiang.zhang components: Documentation nosy: xiang.zhang priority: normal severity: normal stage: patch review status: open title: Fix wrong indentation of timeit.Timer's documenation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 05:21:30 2017 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Mon, 27 Feb 2017 10:21:30 +0000 Subject: [New-bugs-announce] [issue29663] Make collections.deque json serializable Message-ID: <1488190890.97.0.257287797026.issue29663@psf.upfronthosting.co.za> New submission from Tarek Ziad?: collections.deque could be serialized in JSON as a simple array. The only thing we can lose in the process is the maxlen value, but I think it's a decent behaviour to ignore it when encoding and to set it to None when decoding. ---------- components: Library (Lib) messages: 288629 nosy: rhettinger, tarek priority: normal severity: normal status: open title: Make collections.deque json serializable versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 05:38:18 2017 From: report at bugs.python.org (Muhammad Salem) Date: Mon, 27 Feb 2017 10:38:18 +0000 Subject: [New-bugs-announce] [issue29664] zip() python 3 documentation not working at all ! Message-ID: <1488191898.8.0.43175985321.issue29664@psf.upfronthosting.co.za> New submission from Muhammad Salem: this code from the python documentation itself not working! >>> x = [1, 2, 3] >>> y = [4, 5, 6] >>> zipped = zip(x, y) this code is copied from the python 3 official documentation itself even though it is working for me I am using python 3.5.2 on ubuntu 16.04 LTS ---------- components: Interpreter Core messages: 288631 nosy: Muhammad Salem priority: normal severity: normal status: open title: zip() python 3 documentation not working at all ! type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 05:50:47 2017 From: report at bugs.python.org (Muhammad Salem) Date: Mon, 27 Feb 2017 10:50:47 +0000 Subject: [New-bugs-announce] [issue29665] how to edit or delete issues created by me in bug tracker Message-ID: <1488192647.78.0.178839998452.issue29665@psf.upfronthosting.co.za> Changes by Muhammad Salem : ---------- nosy: Muhammad Salem priority: normal severity: normal status: open title: how to edit or delete issues created by me in bug tracker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 08:48:31 2017 From: report at bugs.python.org (STINNER Victor) Date: Mon, 27 Feb 2017 13:48:31 +0000 Subject: [New-bugs-announce] [issue29666] Issue in enum documentation Message-ID: <1488203311.1.0.764284916797.issue29666@psf.upfronthosting.co.za> New submission from STINNER Victor: https://docs.python.org/dev/library/enum.html "This module defines four enumeration classes that can be used to define unique sets of names and values: Enum, IntEnum, and IntFlags" Enum, IntEnum, IntFlag: I count 3 classes, no 4? Moreover, the correct class name is IntFlag, not IntFlags. Or did I miss something? haypo at selma$ ./python Python 3.7.0a0 (default, Feb 25 2017, 04:30:32) >>> import enum >>> enum.IntFlags ... AttributeError: module 'enum' has no attribute 'IntFlags' ---------- assignee: docs at python components: Documentation keywords: easy messages: 288642 nosy: docs at python, haypo priority: normal severity: normal status: open title: Issue in enum documentation versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 12:11:41 2017 From: report at bugs.python.org (Bob Kline) Date: Mon, 27 Feb 2017 17:11:41 +0000 Subject: [New-bugs-announce] [issue29667] socket module sometimes loses response packets Message-ID: <1488215501.4.0.436225777411.issue29667@psf.upfronthosting.co.za> New submission from Bob Kline: The socket module does not always return response packets which are successfully delivered to the client host. We ran into this problem with an HTTP request for which socket.recv() raised an exception instead of returning the 301 redirection response which the web server sent back: socket.error: [Errno 10054] An existing connection was forcibly closed by the remote host We did some packet tracing, and saw that there were six packets exchanged for the connection: client: [SYN] server: [SYN,ACK] client: [ACK] client: GET /cam HTTP/1.1 ...\r\n\r\n server: HTTP/1.0 301 Moved Permanently ...\r\n\r\n server: [RST,ACK] The failure appears to be timing dependent. If the 301 response is processed quickly enough (the usual case), the socket.recv() call returns it successfully to the caller. If sufficient delay is introduced, however, the 301 response is discarded, and the exception is raised. This can happen, for example, if the socket library has to take the time to handle setting up a requested timeout. On a slow enough machine, the following code will reproduce the problem: import socket s = socket.create_connection(("www.cancer.gov", 80), timeout=5) s.sendall("GET /cam HTTP/1.1\r\nHost: www.cancer.gov\r\n\r\n") print s.recv(8192) You might have to stick a time.sleep(.5) call right in front of the s.recv() call if you can't find a slow enough machine to test on. This appears to be a Windows-specific problem, as I can't reproduce it on a Linux or OS X client, no matter how much of a delay is introduced. Platform: Windows (any version) with Python 2.7 or Python 3.6. ---------- components: Library (Lib) messages: 288648 nosy: bkline priority: normal severity: normal status: open title: socket module sometimes loses response packets type: behavior versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 12:25:39 2017 From: report at bugs.python.org (Rafael Capucho) Date: Mon, 27 Feb 2017 17:25:39 +0000 Subject: [New-bugs-announce] [issue29668] f-strings don't change the values as expected. Message-ID: <1488216339.29.0.0564284707664.issue29668@psf.upfronthosting.co.za> New submission from Rafael Capucho: In the attached file, the lines 4 and 6 have the same structure, the line 4 changes the value of {a} properly, the line 6 didn't. Thank you. ---------- components: Interpreter Core files: crazy.png messages: 288649 nosy: Rafael Capucho priority: normal severity: normal status: open title: f-strings don't change the values as expected. type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46673/crazy.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 13:58:07 2017 From: report at bugs.python.org (Marco Buttu) Date: Mon, 27 Feb 2017 18:58:07 +0000 Subject: [New-bugs-announce] [issue29669] Missing import of bisect in the documentation examples Message-ID: <1488221887.03.0.391509219567.issue29669@psf.upfronthosting.co.za> New submission from Marco Buttu: There is no import of bisect.bisect() and bisect.bisect_left() in the documentation. IMHO the examples are clearer and more complete if we import these functions, as in the attached patch. ---------- assignee: docs at python components: Documentation files: import_bisect.patch keywords: patch messages: 288663 nosy: docs at python, marco.buttu priority: normal severity: normal status: open title: Missing import of bisect in the documentation examples type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46676/import_bisect.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 15:33:10 2017 From: report at bugs.python.org (Matthew Hall) Date: Mon, 27 Feb 2017 20:33:10 +0000 Subject: [New-bugs-announce] [issue29670] argparse: does not respect required args pre-populated into namespace Message-ID: <1488227590.23.0.0462095560451.issue29670@psf.upfronthosting.co.za> New submission from Matthew Hall: I have some Python code which takes advantage of the ability to prepopulate the argparse Namespace before passing it to argparse. This allows me to read sensitive settings such as usernames and passwords from DBs, environment variables, etc. in addition to the CLI for security so they don't appear as process arguments anyone could see. Some of these scripts have usernames and passwords as required arguments since they cannot function without them. Unfortunately you hit this bug when you load them into the namespace yourself from some secure place of your choice and then pass them in: args = parser.parse_args(argv, namespace) The following argparse code which doesn't respect that they were present already and throws a fatal error. In addition, the parse_known_args function is 246 lines of code which uses ugly nested cheater functions, and the seen_actions variable is in the stack of the function not a member variable, so there is no way you can cleanly override or work around the behavior with a subclass, either by replacing the function (too massive) or by fixing up the seen_actions variable (can't get to it on the stack from outside). So, I suggest that this code should to be fixed so that it will respect any existing values in the Namespace if they are present: # make sure all required actions were present, and convert defaults. for action in self._actions: if action not in seen_actions: if action.required: name = _get_action_name(action) self.error(_('argument %s is required') % name) ---------- components: Library (Lib) messages: 288667 nosy: mhcptg priority: normal severity: normal status: open title: argparse: does not respect required args pre-populated into namespace type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 15:35:12 2017 From: report at bugs.python.org (Kevin Mills) Date: Mon, 27 Feb 2017 20:35:12 +0000 Subject: [New-bugs-announce] [issue29671] Add function to gc module to check if any reference cycles have been reclaimed. Message-ID: <1488227712.23.0.994684569809.issue29671@psf.upfronthosting.co.za> New submission from Kevin Mills: The intro paragraph for the gc module's documentation says: > Since the collector supplements the reference counting already used in Python, you can disable the collector if you are sure your program does not create reference cycles. How would you ever be sure of that? While you can prevent reference cycles in your own code, what about your dependencies? You'd have to look through the code of all of your dependencies and transitive dependencies (including the standard library) to verify that none introduce reference cycles. And then you'd have to redo that work when upgrading any of them. I propose adding a function to the gc module that returns True if the gc has reclaimed at least one reference cycle in the course of the current program's execution. With that, it would be possible to, a program could, before it exits, force a collection and then check if any reference cycles were found over the program's lifetime, and then the programmer could use that information to decide whether they can safely turn off the gc or not. Obviously that wouldn't guarantee that you could safely turn of the gc (it's possible that garbage with reference cycles is created on other runs of the program) it would at least be some information. ---------- messages: 288668 nosy: Kevin Mills priority: normal severity: normal status: open title: Add function to gc module to check if any reference cycles have been reclaimed. type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 17:29:56 2017 From: report at bugs.python.org (Gerrit Holl) Date: Mon, 27 Feb 2017 22:29:56 +0000 Subject: [New-bugs-announce] [issue29672] `catch_warnings` context manager causes warnings to be reprinted Message-ID: <1488234596.55.0.435492915134.issue29672@psf.upfronthosting.co.za> New submission from Gerrit Holl: Entering the `catch_warnings` context manager is causing warnings to be printed over and over again, rather than just once as it should. Without such a context manager, the behaviour is as expected: $ cat ./mwe.py #!/usr/bin/env python3.5 import warnings for i in range(3): try: print(i, __warningregistry__) except NameError: print(i, "first warning") warnings.warn("I don't like this.", UserWarning) print(i, __warningregistry__) # with warnings.catch_warnings(): # pass print(i, __warningregistry__) warnings.warn("I don't like this.", UserWarning) $ ./mwe.py 0 first warning ./mwe.py:10: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 0 {'version': 0, ("I don't like this.", , 10): True} 0 {'version': 0, ("I don't like this.", , 10): True} ./mwe.py:15: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 1 {'version': 0, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 1 {'version': 0, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 1 {'version': 0, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 2 {'version': 0, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 2 {'version': 0, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 2 {'version': 0, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} Uncommenting the context manager causes the warning to be printed every time: $ ./mwe.py 0 first warning ./mwe.py:10: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 0 {'version': 0, ("I don't like this.", , 10): True} 0 {'version': 0, ("I don't like this.", , 10): True} ./mwe.py:15: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 1 {'version': 2, ("I don't like this.", , 15): True} ./mwe.py:10: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 1 {'version': 2, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 1 {'version': 2, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} ./mwe.py:15: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 2 {'version': 4, ("I don't like this.", , 15): True} ./mwe.py:10: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) 2 {'version': 4, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} 2 {'version': 4, ("I don't like this.", , 15): True, ("I don't like this.", , 10): True} ./mwe.py:15: UserWarning: I don't like this. warnings.warn("I don't like this.", UserWarning) I think this is undesirable. There is code deep inside a module that I'm using that is using the context manager, and as a consequence, I get warnings printed every time that should be printed only once. See also on Stack Overflow: http://stackoverflow.com/q/42496579/974555 ---------- messages: 288677 nosy: Gerrit.Holl priority: normal severity: normal status: open title: `catch_warnings` context manager causes warnings to be reprinted versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Feb 27 19:02:47 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 28 Feb 2017 00:02:47 +0000 Subject: [New-bugs-announce] [issue29673] Some gdb macros are broken in 3.6 Message-ID: <1488240167.08.0.156874874183.issue29673@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Some gdb macros defined in Misc/gdbinit got broken when _PyUnicode_AsString was renamed to PyUnicode_AsUTF8. (gdb) pystack No symbol "_PyUnicode_AsString" in current context. ---------- messages: 288684 nosy: belopolsky priority: normal severity: normal status: open title: Some gdb macros are broken in 3.6 versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 03:54:10 2017 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Feb 2017 08:54:10 +0000 Subject: [New-bugs-announce] [issue29674] Use GCC __attribute__((alloc_size(x, y))) on PyMem_Malloc() functions Message-ID: <1488272050.61.0.409487721584.issue29674@psf.upfronthosting.co.za> New submission from STINNER Victor: GCC allows to get "size" parameters of functions allocating memory to emit better warning. For example, GCC 7 will detect implicit cast from signed to unsigned integer and emit a warning. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html Example of Python functions that can benefit of this attribute: * PyMem_RawMalloc(), PyMem_RawCalloc(), PyMem_RawRealloc() * PyMem_Malloc(), PyMem_Calloc(), PyMem_Realloc() * PyObject_Malloc(), PyObject_Calloc(), PyObject_Realloc() ---------- messages: 288699 nosy: haypo priority: normal severity: normal status: open title: Use GCC __attribute__((alloc_size(x,y))) on PyMem_Malloc() functions versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 05:42:29 2017 From: report at bugs.python.org (Q) Date: Tue, 28 Feb 2017 10:42:29 +0000 Subject: [New-bugs-announce] [issue29675] SysLogHandler does not seem to always expand %(loglevel)s properly Message-ID: <1488278549.76.0.307223036696.issue29675@psf.upfronthosting.co.za> New submission from Q: On Ubuntu LTS 16.04, SysLogHandler with a custom formatter does not seem to expand loglevel/levelno fields properly, when there are square brackets ( see the attached examples ). Instead, it seems to replace '[%(loglevel)s]' with a '[pid]', and '%(loglevel)s' with 'LOGLEVEL[pid]' . To test, run 'journalctl -f | grep test_test_test' on one console, and the attached files on another. The output for 'bad.py' looks as follows: === Feb 28 21:30:05 hostname [7117]: logging was configured for process <7117> === And should have looked like: === Feb 28 21:30:05 hostname [INFO]: logging was configured for process <7117> === For 'good.py', the output is as follows: === Feb 28 21:30:04 hostname INFO[7114]: logging was configured for process <7114> === and should have probably been: === Feb 28 21:30:04 hostname INFO: logging was configured for process <7114> === Kind regards, /t13 ---------- files: bad.py messages: 288702 nosy: thread13 priority: normal severity: normal status: open title: SysLogHandler does not seem to always expand %(loglevel)s properly versions: Python 2.7 Added file: http://bugs.python.org/file46679/bad.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 06:34:24 2017 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 28 Feb 2017 11:34:24 +0000 Subject: [New-bugs-announce] [issue29676] verbose output of test_cprofile Message-ID: <1488281664.18.0.494134456081.issue29676@psf.upfronthosting.co.za> New submission from Xiang Zhang: Recently when I run the test suite test_cprofile always produces some verbose info but won't fail. This is not the case before. I am not sure this is a bug or not. git bisect tells me https://github.com/python/cpython/commit/5566bbb8d563646d83e8172410fa0c085e8233b1 is responsible. I also see the verbose info on some buildbots. [cpython]$ ./python -m test test_cprofile Run tests sequentially 0:00:00 [1/1] test_cprofile Stats.print_callers output for Profile doesn't fit expectation! --- +++ @@ -1,15 +1,16 @@ -profilee.py:110(__getattr__) <- 16 0.016 0.016 profilee.py:98(subhelper) -profilee.py:25(testfunc) <- 1 0.270 1.000 :1() -profilee.py:35(factorial) <- 1 0.014 0.130 profilee.py:25(testfunc) - 20/3 0.130 0.147 profilee.py:35(factorial) - 2 0.006 0.040 profilee.py:84(helper2_indirect) -profilee.py:48(mul) <- 20 0.020 0.020 profilee.py:35(factorial) -profilee.py:55(helper) <- 2 0.040 0.600 profilee.py:25(testfunc) -profilee.py:73(helper1) <- 4 0.116 0.120 profilee.py:55(helper) -profilee.py:84(helper2_indirect) <- 2 0.000 0.140 profilee.py:55(helper) -profilee.py:88(helper2) <- 6 0.234 0.300 profilee.py:55(helper) - 2 0.078 0.100 profilee.py:84(helper2_indirect) -profilee.py:98(subhelper) <- 8 0.064 0.080 profilee.py:88(helper2) -{built-in method builtins.hasattr} <- 4 0.000 0.004 profilee.py:73(helper1) - 8 0.000 0.008 profilee.py:88(helper2) -{built-in method sys.exc_info} <- 4 0.000 0.000 profilee.py:73(helper1) +profilee.py:110(__getattr__) <- 16 0.016 0.016 profilee.py:98(subhelper) +profilee.py:25(testfunc) <- 1 0.270 1.000 :1() +profilee.py:35(factorial) <- 1 0.014 0.130 profilee.py:25(testfunc) + 20/3 0.130 0.147 profilee.py:35(factorial) + 2 0.006 0.040 profilee.py:84(helper2_indirect) +profilee.py:48(mul) <- 20 0.020 0.020 profilee.py:35(factorial) +profilee.py:55(helper) <- 2 0.040 0.600 profilee.py:25(testfunc) +profilee.py:73(helper1) <- 4 0.116 0.120 profilee.py:55(helper) +profilee.py:84(helper2_indirect) <- 2 0.000 0.140 profilee.py:55(helper) +profilee.py:88(helper2) <- 6 0.234 0.300 profilee.py:55(helper) + 2 0.078 0.100 profilee.py:84(helper2_indirect) +profilee.py:98(subhelper) <- 8 0.064 0.080 profilee.py:88(helper2) +{built-in method builtins.hasattr} <- 4 0.000 0.004 profilee.py:73(helper1) + 8 0.000 0.008 profilee.py:88(helper2) +{built-in method sys.exc_info} <- 4 0.000 0.000 profilee.py:73(helper1) +{method 'append' of 'list' objects} <- 4 0.000 0.000 profilee.py:73(helper1) Stats.print_callees output for Profile doesn't fit expectation! --- +++ @@ -1,16 +1,16 @@ -:1() -> 1 0.270 1.000 profilee.py:25(testfunc) -profilee.py:110(__getattr__) -> -profilee.py:25(testfunc) -> 1 0.014 0.130 profilee.py:35(factorial) - 2 0.040 0.600 profilee.py:55(helper) -profilee.py:35(factorial) -> 20/3 0.130 0.147 profilee.py:35(factorial) - 20 0.020 0.020 profilee.py:48(mul) -profilee.py:48(mul) -> -profilee.py:55(helper) -> 4 0.116 0.120 profilee.py:73(helper1) - 2 0.000 0.140 profilee.py:84(helper2_indirect) - 6 0.234 0.300 profilee.py:88(helper2) -profilee.py:73(helper1) -> 4 0.000 0.004 {built-in method builtins.hasattr} -profilee.py:84(helper2_indirect) -> 2 0.006 0.040 profilee.py:35(factorial) - 2 0.078 0.100 profilee.py:88(helper2) -profilee.py:88(helper2) -> 8 0.064 0.080 profilee.py:98(subhelper) -profilee.py:98(subhelper) -> 16 0.016 0.016 profilee.py:110(__getattr__) -{built-in method builtins.hasattr} -> 12 0.012 0.012 profilee.py:110(__getattr__) +:1() -> 1 0.270 1.000 profilee.py:25(testfunc) +profilee.py:110(__getattr__) -> +profilee.py:25(testfunc) -> 1 0.014 0.130 profilee.py:35(factorial) + 2 0.040 0.600 profilee.py:55(helper) +profilee.py:35(factorial) -> 20/3 0.130 0.147 profilee.py:35(factorial) + 20 0.020 0.020 profilee.py:48(mul) +profilee.py:48(mul) -> +profilee.py:55(helper) -> 4 0.116 0.120 profilee.py:73(helper1) + 2 0.000 0.140 profilee.py:84(helper2_indirect) + 6 0.234 0.300 profilee.py:88(helper2) +profilee.py:73(helper1) -> 4 0.000 0.004 {built-in method builtins.hasattr} +profilee.py:84(helper2_indirect) -> 2 0.006 0.040 profilee.py:35(factorial) + 2 0.078 0.100 profilee.py:88(helper2) +profilee.py:88(helper2) -> 8 0.064 0.080 profilee.py:98(subhelper) +profilee.py:98(subhelper) -> 16 0.016 0.016 profilee.py:110(__getattr__) +{built-in method builtins.hasattr} -> 12 0.012 0.012 profilee.py:110(__getattr__) 1 test OK. Total duration: 73 ms Tests result: SUCCESS ---------- components: Tests messages: 288707 nosy: inada.naoki, xiang.zhang priority: normal severity: normal status: open title: verbose output of test_cprofile type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 07:30:24 2017 From: report at bugs.python.org (ChrisRands) Date: Tue, 28 Feb 2017 12:30:24 +0000 Subject: [New-bugs-announce] [issue29677] 'round()' accepts a negative integer for ndigits Message-ID: <1488285024.25.0.0499728148151.issue29677@psf.upfronthosting.co.za> New submission from ChrisRands: With a negative integer for ndigits the output from 'round()', for example 'round(3, -2)', is always zero ('0' for 'int.__round__' and '0.0' or '-0.0' for 'float.__round__'). I think either it should raise an exception or the docs should be updated to reflect the current behavior. The docs are currently silent on this: https://docs.python.org/3/library/functions.html#round I don't know C, but there appears to be a note in the source about this implying it is the desired behavior but without an explanation: "For ndigits < NDIGITS_MIN, x always rounds to +-0.0.": https://github.com/python/cpython/blob/6f0eb93183519024cb360162bdd81b9faec97ba6/Objects/floatobject.c Anyway, I can't imagine an actual use case for negative ndigits. ---------- messages: 288710 nosy: ChrisRands priority: normal severity: normal status: open title: 'round()' accepts a negative integer for ndigits _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 13:32:28 2017 From: report at bugs.python.org (Sergey) Date: Tue, 28 Feb 2017 18:32:28 +0000 Subject: [New-bugs-announce] [issue29678] email.Message.get_params decodes only first one header value Message-ID: <1488306748.36.0.996484861833.issue29678@psf.upfronthosting.co.za> New submission from Sergey: email.Message class has method get_params() that can decode(unquote) header values in compliance with RFC2231 and RFC2047. But if in email message exists multiple headers with the same key it can't be used to decode other headers than first. In my application I could use: headers = message.items() for key, value in headers: cleanValue = message.get_params(value=value) print(key, cleanValue) Also have posted question on stackoverflow: http://stackoverflow.com/questions/42502312/python-3-email-package-how-decode-given-header-value ---------- components: email messages: 288720 nosy: barry, pi314159, r.david.murray priority: normal severity: normal status: open title: email.Message.get_params decodes only first one header value type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 18:21:09 2017 From: report at bugs.python.org (Jelle Zijlstra) Date: Tue, 28 Feb 2017 23:21:09 +0000 Subject: [New-bugs-announce] [issue29679] Add @contextlib.asynccontextmanager Message-ID: <1488324069.16.0.696570474408.issue29679@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: An async equivalent of @contextmanager would be an obvious use case for async generators and the async with statement. In my own code, I have several async context objects that could have been written more concisely if @asynccontextmanager was available. I'll be working on a PR to implement this. ---------- components: Library (Lib) messages: 288729 nosy: Jelle Zijlstra priority: normal severity: normal status: open title: Add @contextlib.asynccontextmanager versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 21:36:44 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 01 Mar 2017 02:36:44 +0000 Subject: [New-bugs-announce] [issue29680] gdb/libpython.py does not work with gdb 7.2 Message-ID: <1488335804.47.0.122589974382.issue29680@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Printing the backtrace in gdb results in Python errors: (gdb) bt ... #6 0x00007ffff7ba9745 in _PyEval_EvalCodeWithName (_co=, globals=Traceback (most recent call last): File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 1358, in to_string return pyop.get_truncated_repr(MAX_OUTPUT_LEN) File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 243, in get_truncated_repr self.write_repr(out, set()) File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 702, in write_repr for pyop_key, pyop_value in self.iteritems(): File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 669, in iteritems entries, nentries = self._get_entries(keys) File "/home/a/.virtualenvs/3.6g/bin/python3.6-gdb.py", line 717, in _get_entries except gdb.error: AttributeError: 'module' object has no attribute 'error' ... ---------- assignee: belopolsky messages: 288730 nosy: belopolsky priority: normal severity: normal status: open title: gdb/libpython.py does not work with gdb 7.2 type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Feb 28 22:32:30 2017 From: report at bugs.python.org (Marshall Giguere) Date: Wed, 01 Mar 2017 03:32:30 +0000 Subject: [New-bugs-announce] [issue29681] getopt fails to handle option with missing value in middle of list Message-ID: <1488339150.93.0.468964367944.issue29681@psf.upfronthosting.co.za> New submission from Marshall Giguere: Python 3.4.3 (default, Nov 17 2016, 01:08:31) [GCC 4.8.4] on linux >>> from getopt import getopt >>> argv = [ '-a', '-b', '-c', '-d', 'foo'] >>> opts, args = getopt( argv, 'abc:d:') >>> opts [('-a', ''), ('-b', ''), ('-c', '-d')] >>> args ['foo'] Expected behavior: opts = [('-a', ''), ('-b', ''), ('-c', ''), ('-d', 'foo')] Throws execption: getopt.GetoptError: option -c requires argument Note that -c requires a value, getopt swallows the next option '-d' as the argument to -c. However, if -c is the last option on the command line getopt properly throws an execption "getopt.GetoptError: option -c requires argument". The documentation states that getopt will throw an exception when an option requiring a value is missing and exception will be thrown. "exception getopt.GetoptError This is raised when an unrecognized option is found in the argument list or when an option requiring an argument is given none." The option -c requires an argument, none was given, no exception is thrown. Instead the next option, '-d', is taken as the argument. I have also tried this test on 2.7 with the same result. ---------- components: Extension Modules messages: 288731 nosy: Marshall Giguere priority: normal severity: normal status: open title: getopt fails to handle option with missing value in middle of list type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________