[issue31265] Remove doubly-linked list from C OrderedDict

[INADA Naoki]

INADA Naoki added the comment:

> Eric Snow added the comment:
>
> On Sun, Sep 10, 2017 at 10:27 PM, Serhiy Storchaka
>  wrote:
>> Note that mixed insertion and deletion is worst-case O(n) in current 
>> implementation.
>
> Could you elaborate?  Note that every operation of the current
> implementation matches the complexity of the Python implementation.
>

It means rebuilding hash table to clean up dummy entries.
So, even when dict size is not increasing, remove + insert loop has
worst case O(n), amortized O(1) complexity.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31265] Remove doubly-linked list from C OrderedDict

[INADA Naoki]

INADA Naoki added the comment:

> I would side with Inada in thinking they both give the same amortized 
> complexity, but beyond that, benchmarks are the real answer.  There is little 
> value in keeping the current implementation of OrderedDict *if* benchmarks 
> show that it is rarely faster.

As I wrote in here:
https://bugs.python.org/issue31265#msg300757

PyPy-like ODict implementation is:

* 1000 less lines of code
* 50% less memory usage
* 15% faster creation
* 100% (2x) faster iteration
* 20% slower move_to_end
* 40% slower comparison

Since current implementation is still draft, there are some
potential optimization.

* Optimize over allocation ratio for move_to_end.  I have not tried to adjust 
it for nice balance between speed and space.
* I used temporary list to comparing keys safely.  But it can be avoided like 
normal iteration.

I'll try them in this or next week.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31426] Segfault during GC of generator object; invalid gi_frame?

[Ian Wienand]

New submission from Ian Wienand:

Using 3.5.2-2ubuntu0~16.04.3 (Xenial) we see an occasional segfault during 
garbage collection of a generator object

A full backtrace is attached, but the crash appears to be triggered inside 
gen_traverse during gc

---
(gdb) info args
gen = 0x7f22385f0150
visit = 0x50eaa0 
arg = 0x0

(gdb) print *gen
$109 = {ob_base = {ob_refcnt = 1, ob_type = 0xa35760 }, gi_frame = 
0x386aed8, gi_running = 1 '\001', gi_code = , 
gi_weakreflist = 0x0, gi_name = 'linesplit', gi_qualname = 'linesplit'}
---

I believe gen_traverse is doing the following

---
static int
gen_traverse(PyGenObject *gen, visitproc visit, void *arg)
{
Py_VISIT((PyObject *)gen->gi_frame);
Py_VISIT(gen->gi_code);
Py_VISIT(gen->gi_name);
Py_VISIT(gen->gi_qualname);
return 0;
}
---

The problem here being that this generator's gen->gi_frame has managed to 
acquire a NULL object type but still has references

---
(gdb) print *gen->gi_frame
$112 = {ob_base = {ob_base = {ob_refcnt = 2, ob_type = 0x0}, ob_size = 0}, 
f_back = 0x0, f_code = 0xca3e4fd8950fef91, ...
---

Thus it gets visited and it doesn't go well.

I have attached the py-bt as well, it's very deep with ansible, multiprocessing 
forking, imp.load_source() importing ... basically a nightmare.  I have not 
managed to get it down to any sort of minimal test case unfortunately.  This 
happens fairly infrequently, so suggests a race.  The generator in question has 
a socket involved:

---
def linesplit(socket):
buff = socket.recv(4096).decode("utf-8")
buffering = True
while buffering:
if "\n" in buff:
(line, buff) = buff.split("\n", 1)
yield line + "\n"
else:
more = socket.recv(4096).decode("utf-8")
if not more:
buffering = False
else:
buff += more
if buff:
yield buff
---

Wild speculation but maybe something to do with finalizing generators with 
file-descriptors across fork()?

At this point we are trying a work-around of not having the above socket 
reading routine in a generator but just a "regular" loop.  As it triggers as 
part of a production roll-out I'm not sure we can do too much more debugging.  
Unless this rings any immediate bells for people, we can probably just have 
this for tracking at this point.  [1] is the original upstream issue
 
[1] https://storyboard.openstack.org/#!/story/2001186#comment-17441

--
components: Interpreter Core
files: crash-bt.txt
messages: 301943
nosy: iwienand
priority: normal
severity: normal
status: open
title: Segfault during GC of generator object; invalid gi_frame?
type: crash
versions: Python 3.5
Added file: https://bugs.python.org/file47134/crash-bt.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31426] Segfault during GC of generator object; invalid gi_frame?

[Ian Wienand]

Changes by Ian Wienand :


Added file: https://bugs.python.org/file47135/crash-py-bt.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31426] Segfault during GC of generator object; invalid gi_frame?

[STINNER Victor]

STINNER Victor added the comment:

Python 3.5 moved to security only fixes recently, it doesn't accept bug fixes 
anymore:
https://devguide.python.org/#status-of-python-branches

It would be nice to Python 3.5.4 at least, or better: Python 3.6.x.


> (gdb) print *gen->gi_frame
> $112 = {ob_base = {ob_base = {ob_refcnt = 2, ob_type = 0x0}, ob_size = 0}, 
> f_back = 0x0, f_code = 0xca3e4fd8950fef91, ...

ob_type should never be NULL for an object still reachable and with a reference 
count different than zero. It seems like a bug in a C extension. It would help 
to test your application on a Python compiled in debug mode.

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31426] Segfault during GC of generator object; invalid gi_frame?

[STINNER Victor]

STINNER Victor added the comment:

I pointed bpo-26617 to Ian since Python 3.5.2 contains this GC crash, but it 
seems like it's not the same bug.

--
nosy: +pitrou, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31426] [3.5] gen_traverse(): gi_frame.ob_type=NULL when called by subtract_refs() during a GC collection

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +yselivanov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31426] [3.5] gen_traverse(): gi_frame.ob_type=NULL when called by subtract_refs() during a GC collection

[STINNER Victor]

Changes by STINNER Victor :


--
title: Segfault during GC of generator object; invalid gi_frame? -> [3.5] 
gen_traverse(): gi_frame.ob_type=NULL when called by subtract_refs() during a 
GC collection

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31426] [3.5] gen_traverse(): gi_frame.ob_type=NULL when called by subtract_refs() during a GC collection

[STINNER Victor]

STINNER Victor added the comment:

> I pointed bpo-26617 to Ian since Python 3.5.2 contains this GC crash, but it 
> seems like it's not the same bug.

Ah, I found an issue which had bpo-26617 in subtract_refs():
https://stackoverflow.com/questions/39990934/debugging-python-segmentation-faults-in-garbage-collection

So it's not only update_refs() called during GC collection.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31426] [3.5] crash in gen_traverse(): gi_frame.ob_type=NULL, called by subtract_refs() during a GC collection

[STINNER Victor]

Changes by STINNER Victor :


--
title: [3.5] gen_traverse(): gi_frame.ob_type=NULL when called by 
subtract_refs() during a GC collection -> [3.5] crash in gen_traverse(): 
gi_frame.ob_type=NULL, called by subtract_refs() during a GC collection

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1612262] Class Browser doesn't show internal classes

[Nick Coghlan]

Nick Coghlan added the comment:

I think a bundled copy as idlelib._pyclbr in the 3.6 branch would be within the 
intent of PEP 434.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16251] pickle special methods are looked up on the instance rather than the type

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

What the problem tries to solve PR 3508? Swallowing all exceptions looks like 
an antipattern to me. This puts the problem under the carpet. Rather than 
failing and allowing the programmer to fix the picleability of its class, this 
can silently produce incorrect pickle data. By swallowing MemoryError and 
RecursionError this changes the behavior of objects in an environment with 
limited resources: lack of memory or calling deep in the calling stack. This 
adds heisenbugs. An infinity recursion spends CPU time, and in unlucky cases 
can cause a crash. It is better to detect it earlier than just swallow 
RecursionError.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27099] IDLE: turn built-in extensions into regular modules

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
pull_requests: +3505

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31404] undefined behavior and crashes in case of a bad sys.modules

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I haven't finished reviewing PR 1638. I'm not sure that this change is worth. 
It breaks a code that assumes that sys.module is a dict, and I afraid it slows 
down importing. Maybe revert this change until resolving all problems?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31408] Leak in typeobject.c

[Stefan Krah]

Stefan Krah added the comment:

It's fixed, thanks!

--
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Reference leaks introduced by bpo-30860

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27099] IDLE: turn built-in extensions into regular modules

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3506

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27099] IDLE: turn built-in extensions into regular modules

[Terry J. Reedy]

Terry J. Reedy added the comment:


New changeset adb4cd2a2a59019ac6955e0fd531c9fec9258962 by Terry Jan Reedy in 
branch 'master':
bpo-27099: Finish updating IDLE doc and help text. (#3510)
https://github.com/python/cpython/commit/adb4cd2a2a59019ac6955e0fd531c9fec9258962


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31427] Proposed addition to Windows FAQ

[Stephan Houben]

New submission from Stephan Houben:

Several people have asked on python-list why they are running into these errors.

Python 3.6.0 can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing. 

The solution is to install KB 2999226 "Update for Universal C Runtime in 
Windows". 
https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows

Propose to add this as a Windows FAQ.

--
assignee: docs@python
components: Documentation
messages: 301952
nosy: Stephan Houben, docs@python
priority: normal
severity: normal
status: open
title: Proposed addition to Windows FAQ
type: enhancement
versions: Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31428] ElementTree.Element.__deepcopy__() raises a SystemError in case of a bad memo

[Oren Milman]

New submission from Oren Milman:

The following code causes ElementTree.Element.__deepcopy__() to raise a
SystemError:

class BadMemo:
def get(*args):
return None

import xml.etree.ElementTree
xml.etree.ElementTree.Element('foo').__deepcopy__(BadMemo())


this is because _elementtree_Element___deepcopy__() (in Modules/_elementtree.c)
assumes that memo is a dictionary, and passes it to PyDict_SetItem(), which
raises the SystemError.

--
components: XML
messages: 301953
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: ElementTree.Element.__deepcopy__() raises a SystemError in case of a bad 
memo
type: behavior
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31428] ElementTree.Element.__deepcopy__() raises a SystemError in case of a bad memo

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 2.7, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27099] IDLE: turn built-in extensions into regular modules

[Terry J. Reedy]

Terry J. Reedy added the comment:


New changeset 01dcaa5c996baf019656cf51451bb1b6ecd720fa by Terry Jan Reedy (Miss 
Islington (bot)) in branch '3.6':
[3.6] bpo-27099: Finish updating IDLE doc and help text. (GH-3510) (#3511)
https://github.com/python/cpython/commit/01dcaa5c996baf019656cf51451bb1b6ecd720fa


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31428] ElementTree.Element.__deepcopy__() raises a SystemError in case of a bad memo

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I suppose the Python implementation supports arbitrary mapping, not just dict. 
We could use general mapping API in the C implementation, but I think it isn't 
worth. __deepcopy__ is used internally by copy.deepcopy(), which always passes 
a dict. I think it isn't worth to backport a fix, and it doesn't need tests. 
The behavior of calling __deepcopy__ with non-dict is implementation detail. 
But it shouldn't crash or raise SystemError.

--
versions:  -Python 2.7, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31428] ElementTree.Element.__deepcopy__() raises a SystemError in case of a bad memo

[Oren Milman]

Changes by Oren Milman :


--
keywords: +patch
pull_requests: +3507
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31421] IDLE doc: add section on developing tkinter apps.

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
keywords: +patch
pull_requests: +3508
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31421] IDLE doc: add section on developing tkinter apps.

[Terry J. Reedy]

Terry J. Reedy added the comment:


New changeset 98758bc67fb39b74bab368bef8ff3b34554c77c8 by Terry Jan Reedy in 
branch 'master':
bpo-31421: Document how IDLE runs tkinter programs. (#3513)
https://github.com/python/cpython/commit/98758bc67fb39b74bab368bef8ff3b34554c77c8


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31421] IDLE doc: add section on developing tkinter apps.

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3509

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31429] TLS cipher suite compile time option for downstream

[Christian Heimes]

New submission from Christian Heimes:

Python overrides OpenSSL's default cipher suites because the default selection 
used to be pretty bad and insecure. Python disables cipher suites with insecure 
algorithm such as RC4, MD5, DES, and 3DES. The SSL module has hard-coded cipher 
strings for SSLContext and ssl.create_default_context() in multiple places:

* https://github.com/python/cpython/blob/v3.6.2/Modules/_ssl.c#L2693
* https://github.com/python/cpython/blob/v3.6.2/Lib/ssl.py#L387
* https://github.com/python/cpython/blob/v3.6.2/Lib/ssl.py#L503

However the cipher suite overrides makes it harder for vendors and downstream 
to enforce consistent policies. For example the hard-coded strings disable 
Fedora's crypto policy, https://fedoraproject.org/wiki/Changes/CryptoPolicy . 
Fedora has patched OpenSSL to support a "PROFILE=SYSTEM" cipher suite string. 
The string causes OpenSSL to read crypto settings from a system wide 
configuration file.

In order to make it easier to override the default string, Python should have a 
configure option --with-ssl-default-suite that defines a PY_SSL_DEFAULT_SUITE 
macro. In the absence of the option / macro, Python shall set a sensible 
default suite. Application are encouraged to use this default suite list. They 
are still free to override the default by calling SSLContext's set_ciphers() 
method.

Fedora's OpenSSL patch: 
https://src.fedoraproject.org/cgit/rpms/openssl.git/tree/openssl-1.1.0-system-cipherlist.patch?h=f26

--
assignee: christian.heimes
components: SSL
messages: 301957
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: TLS cipher suite compile time option for downstream
type: security
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31265] Remove doubly-linked list from C OrderedDict

[Eric Snow]

Eric Snow added the comment:

> It means rebuilding hash table to clean up dummy entries.
> So, even when dict size is not increasing, remove + insert loop has
> worst case O(n), amortized O(1) complexity.

Ah, so it matches the pure Python implementation then.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31427] Proposed addition to Windows FAQ

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

Is this only a problem with 3.6.0 or >= 3.6.0?

--
components: +Windows
nosy: +Mariatta, paul.moore, steve.dower, tim.golden, zach.ware
stage:  -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31421] IDLE doc: add section on developing tkinter apps.

[Terry J. Reedy]

Terry J. Reedy added the comment:


New changeset 4d7807ab9ad9f990e948d250bbb390b23a790764 by Terry Jan Reedy (Miss 
Islington (bot)) in branch '3.6':
[3.6] bpo-31421: Document how IDLE runs tkinter programs. (GH-3513) (#3514)
https://github.com/python/cpython/commit/4d7807ab9ad9f990e948d250bbb390b23a790764


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31421] IDLE doc: add section on developing tkinter apps.

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31401] Dynamic compilation that uses function in comprehension fails when compiled inside function

[R. David Murray]

R. David Murray added the comment:

Hmm.  I must have made a mistake when I ran (jpc's) test on 3.7.  It is failing 
with the NameError for me when I try it again.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: compile error -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16251] pickle special methods are looked up on the instance rather than the type

[Łukasz Langa]

Łukasz Langa added the comment:

> What the problem tries to solve PR 3508?

The two test cases added demonstrate what was impossible to pickle before and 
is now.

> Swallowing all exceptions looks like an antipattern to me.

This is the only thing that we can do faced with custom `__getattr__()` 
implementations, especially when `copy.deepcopy()` creates new objects with 
`cls.__new__()`, something that most class implementers won't expect.

> Rather than failing and allowing the programmer to fix the picleability of 
> its class, this can silently produce incorrect pickle data.

Can you give me an example where this would lead to incorrect pickle data?

> By swallowing MemoryError and RecursionError this changes the behavior of 
> objects in an environment with limited resources: lack of memory or calling 
> deep in the calling stack. This adds heisenbugs.

This is what `hasattr()` in Python 2 did.  This is why in Python 2 the 
`RecursionError` example I added to the tests was actually working just fine.

--
nosy: +lukasz.langa
stage: patch review -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16251] pickle special methods are looked up on the instance rather than the type

[Łukasz Langa]

Changes by Łukasz Langa :


--
versions: +Python 3.6, Python 3.7 -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31428] ElementTree.Element.__deepcopy__() raises a SystemError in case of a bad memo

[Serhiy Storchaka]

Serhiy Storchaka added the comment:


New changeset d056818ed2ade6d28190a375d7183f4aef9caa55 by Serhiy Storchaka 
(Oren Milman) in branch 'master':
bpo-31428: Prevent raising a SystemError in case the memo arg of 
ElementTree.Element.__deepcopy__() isn't a dictionary. (#3512)
https://github.com/python/cpython/commit/d056818ed2ade6d28190a375d7183f4aef9caa55


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31428] ElementTree.Element.__deepcopy__() raises a SystemError in case of a bad memo

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31417] Use the enumerate function where appropriate

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: rhettinger -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31370] Remove support for threads-less builds

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis added the comment:

Lib/_dummy_thread.py and Lib/dummy_threading.py were deleted, but 
Doc/library/_dummy_thread.rst and Doc/library/dummy_threading.rst still exist.

Probably Doc/whatsnew/3.7.rst should mention that these modules were deleted.

Or maybe they should be restored and firstly deprecated, before deletion in a 
later version of Python.

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31431] SSL: check_hostname should imply CERT_REQUIRED

[Christian Heimes]

New submission from Christian Heimes:

Hostname verification makes not much sense without verifying the certificate 
chain first. At the moment one has to set verify_mode to CERT_REQUIRED first:

>>> import ssl  
>>> 
>>> 
>>>   
>>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLS)
>>> ctx.check_hostname, ctx.verify_mode 
>>> 
>>> 
>>>   
(False, )

>>> ctx.check_hostname = True
Traceback (most recent call last):
  File "", line 1, in 
ValueError: check_hostname needs a SSL context with either CERT_OPTIONAL or 
CERT_REQUIRED
>>> ctx.verify_mode = ssl.CERT_REQUIRED
>>> ctx.check_hostname = True


On the other hand verify mode cannot be set to CERT_NONE without disabling 
check_hostname first. One has to remember to set the values in opposite order!

>>> ctx.verify_mode = ssl.CERT_NONE
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 485, in verify_mode
super(SSLContext, SSLContext).verify_mode.__set__(self, value)  


  
ValueError: Cannot set verify_mode to CERT_NONE when check_hostname is enabled.
>>> ctx.check_hostname = False
>>> ctx.verify_mode = ssl.CERT_NONE


I find this confusing. In order to support PROTOCOL_TLS_CLIENT with 
_create_unverified_context(), I had to modify the code to this abomination:

if not check_hostname:
context.check_hostname = False
if cert_reqs is not None:
context.verify_mode = cert_reqs
if check_hostname:
context.check_hostname = True

Rather than making our users to jump through additional hoops, check_hostname = 
True should just set CERT_REQUIRED. This is a sane and safe default. On the 
other hand, ssl.CERT_NONE shall *not* disable check_hostname and still fail 
with a ValueError if check_hostname is enabled.

By the way we should not suggest CERT_OPTIONAL here, too. For TLS client 
connections, CERT_OPTIONAL is not really optional. CERT_OPTIONAL: 
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_cb), CERT_REQUIRED: 
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, 
verify_cb). According to 
https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_verify.html 
SSL_VERIFY_FAIL_IF_NO_PEER_CERT is ignored in client mode. I'll open a new bug 
report.

--
assignee: christian.heimes
components: SSL
messages: 301967
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: SSL: check_hostname should imply CERT_REQUIRED
type: enhancement
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31431] SSL: check_hostname should imply CERT_REQUIRED

[Christian Heimes]

Changes by Christian Heimes :


--
nosy: +alex, dstufft, janssen

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe crashing with error code C0000005

[STINNER Victor]

New submission from STINNER Victor:

On the AMD64 Windows10 2.7 buildbot, the Python compilation fails on mt.exe 
crashing with error code C005 (code -1073741819). It is crashing since the 
build 279 (Mon Sep 4 2017).

This build was trigged by a single change: the commit 
986b7ffc650919b3022ccaa458a843bb8a95d2bd (bpo-30450):

"[2.7] bpo-30450: Pull Windows dependencies from GitHub rather than SVN 
(GH-1783) (GH-3306)"

mt.exe: "The Mt.exe file is a tool that generates signed files and catalogs. It 
is available in the Microsoft Windows Software Development Kit (SDK). Mt.exe 
requires that the file referenced in the manifest be present in the same 
directory as the manifest."

Error C005: "Windows System error (...) Exception Error that occurs when a 
process (application, driver, etc.) tries to execute a processor command that 
references memory outside the space allocated to that process by the Operating 
System."

http://buildbot.python.org/all/builders/AMD64%20Windows10%202.7/builds/279/steps/compile/logs/stdio

(...)
  
"D:\buildarea\2.7.bolen-windows10\build\PCbuild\obj\amd64_Debug\pythoncore\symtable.obj"
  
"D:\buildarea\2.7.bolen-windows10\build\PCbuild\obj\amd64_Debug\pythoncore\sysmodule.obj"
  
"D:\buildarea\2.7.bolen-windows10\build\PCbuild\obj\amd64_Debug\pythoncore\thread.obj"
  
"D:\buildarea\2.7.bolen-windows10\build\PCbuild\obj\amd64_Debug\pythoncore\traceback.obj"
  
"D:\buildarea\2.7.bolen-windows10\build\PCbuild\obj\amd64_Debug\pythoncore\getbuildinfo.obj"
 Creating library 
D:\buildarea\2.7.bolen-windows10\build\PCBuild\\amd64\python27_d.lib and object 
D:\buildarea\2.7.bolen-windows10\build\PCBuild\\amd64\python27_d.exp
  pythoncore.vcxproj -> 
D:\buildarea\2.7.bolen-windows10\build\PCBuild\\amd64\python27_d.dll
Manifest:
  C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe /nologo /verbose 
/outputresource:"D:\buildarea\2.7.bolen-windows10\build\PCBuild\\amd64\python27_d.dll;#2"
 /manifest 
"D:\buildarea\2.7.bolen-windows10\build\PCbuild\obj\amd64_Debug\pythoncore\python27_d.dll.intermediate.manifest"
C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(574,5): error 
MSB6006: "mt.exe" exited with code -1073741819. 
[D:\buildarea\2.7.bolen-windows10\build\PCbuild\pythoncore.vcxproj]
Done Building Project 
"D:\buildarea\2.7.bolen-windows10\build\PCbuild\pythoncore.vcxproj" (Build 
target(s)) -- FAILED.
The target "BeforeGenerateProjectPriFile" listed in a BeforeTargets attribute 
at "C:\Program Files (x86)\MSBuild\Microsoft\NuGet\Microsoft.NuGet.targets 
(186,61)" does not exist in the project, and will be ignored.
The target "BeforeGenerateProjectPriFile" listed in a BeforeTargets attribute 
at "C:\Program Files (x86)\MSBuild\Microsoft\NuGet\Microsoft.NuGet.targets 
(186,61)" does not exist in the project, and will be ignored.
Done Building Project 
"D:\buildarea\2.7.bolen-windows10\build\PCbuild\pcbuild.proj" (Build target(s)) 
-- FAILED.
(...)

--
components: Build, Windows
messages: 301965
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [Windows][2.7] Python 2.7 compilation fails on mt.exe crashing with 
error code C005
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

[STINNER Victor]

STINNER Victor added the comment:

> This change also broke compilation on AMD64 Windows10 2.7 buildbot:
> http://buildbot.python.org/all/builders/AMD64%20Windows10%202.7/builds/279
> (...) error MSB6006: "mt.exe" exited with code -1073741819. (...)

I created the bug bpo-31430 to track this regression.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31370] Remove support for threads-less builds

[STINNER Victor]

STINNER Victor added the comment:

Arfrever: "Lib/_dummy_thread.py and Lib/dummy_threading.py were deleted, but 
Doc/library/_dummy_thread.rst and Doc/library/dummy_threading.rst still exist."

Ah, it should be deleted as well.

Arfrever: "Probably Doc/whatsnew/3.7.rst should mention that these modules were 
deleted."

Right.

Arfrever: "Or maybe they should be restored and firstly deprecated, before 
deletion in a later version of Python."

I don't think that it's worth it, but I suggest to add a warning to Python 3.6 
documentation. Something like the following warning in Python 2.7 documentation 
of the commands module:
"Deprecated since version 2.6: The commands module has been removed in Python 
3. Use the subprocess module instead."
https://docs.python.org/2/library/commands.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31432] Documention for CERT_OPTIONAL is misleading

[Christian Heimes]

Changes by Christian Heimes :


--
nosy: +alex, dstufft, janssen

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31069] test_multiprocessing_spawn and test_multiprocessing_forkserver leak dangling processes

[STINNER Victor]

STINNER Victor added the comment:

Failure on AMD64 FreeBSD 10.x Shared 3.x:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.x%20Shared%203.x/builds/868/steps/test/logs/stdio

...
test_map_chunksize (test.test_multiprocessing_forkserver.WithThreadsTestPool) 
... ok
test_map_handle_iterable_exception 
(test.test_multiprocessing_forkserver.WithThreadsTestPool) ... ok
test_map_no_failfast (test.test_multiprocessing_forkserver.WithThreadsTestPool) 
... ok
test_map_unplicklable 
(test.test_multiprocessing_forkserver.WithThreadsTestPool) ... skipped 'test 
not appropriate for threads'
test_release_task_refs 
(test.test_multiprocessing_forkserver.WithThreadsTestPool) ... ok
test_starmap (test.test_multiprocessing_forkserver.WithThreadsTestPool) ... ok
test_starmap_async (test.test_multiprocessing_forkserver.WithThreadsTestPool) 
... ok
test_terminate (test.test_multiprocessing_forkserver.WithThreadsTestPool) ... ok
test_traceback (test.test_multiprocessing_forkserver.WithThreadsTestPool) ... ok
test_wrapped_exception 
(test.test_multiprocessing_forkserver.WithThreadsTestPool) ... ok
Warning -- Dangling threads: {}
test_active_children 
(test.test_multiprocessing_forkserver.WithThreadsTestProcess) ... ok

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31432] Documention for CERT_OPTIONAL is misleading

[Christian Heimes]

New submission from Christian Heimes:

>From #31431, the documentation of CERT_OPTIONAL and CERT_REQUIRED are 
>misleading. For client side sockets, CERT_OPTIONAL does **NOT** mean that no 
>certificates will be required from the other side of the socket connection. 
>The server **must** provide a cert and the client **requires** the cert to be 
>valid and trusted by trusted CA. 

Internally, the _ssl.c extension module sets:

CERT_NONE: SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE, verify_cb)
CERT_OPTIONAL: SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_cb)
CERT_REQUIRED: SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | 
SSL_VERIFY_FAIL_IF_NO_PEER_CERT, verify_cb)

According to https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_verify.html 
SSL_VERIFY_FAIL_IF_NO_PEER_CERT is ignored in client mode.

This means for client-side sockets:

CERT_NONE: server must provide any cert, verification error does not prevent 
handshake
CERT_OPTIONAL == CERT_REQUIRED
CERT_REQUIRED: server must provide a correct certificate that is trusted by a 
root CA in the trust store of the client


For server-side sockets:

CERT_NONE: Don't ask client for a TLS client auth cert
CERT_OPTIONAL: Ask client for a TLS client auth cert, don't fail if the client 
does not provide one. IIRC the cert must validate and be trusted by a CA in the 
trust store of the server (TODO: verify this)
CERT_REQUIRED: Ask client for TLS client auth cert, fail if client does not 
provide a certificate during the handshake.

--
assignee: docs@python
components: Documentation, SSL
messages: 301970
nosy: christian.heimes, docs@python
priority: normal
severity: normal
status: open
title: Documention for CERT_OPTIONAL is misleading
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31370] Remove support for threads-less builds

[STINNER Victor]

STINNER Victor added the comment:

Oh, Arfrever wrote me on IRC that the removal of dummy_threading broke portage 
on Gentoo: https://bugs.gentoo.org/630730

eventlet also uses dummy_threading:

eventlet/support/dns/entropy.py:23:import dummy_threading as _threading
eventlet/support/dns/resolver.py:29:import dummy_threading as _threading

Hum, maybe we need one release with the deprecated module, and only remove it 
in Python 3.8?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25115] SSL_set_verify_depth not exposed by the ssl module

[Christian Heimes]

Christian Heimes added the comment:

Grant,

I'm not sure I follow you. Do I understand correctly that you want to call 
SSL_CTX_set_verify_depth(ctx, 1), in order to enforce that a peer cert is 
directly signed by your CA?

That doesn't sound like a good use of SSL_CTX_set_verify_depth(), because it 
only works for a simple case without an intermediate CA. Most real-world cases 
have one or more intermediate CAs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31370] Remove support for threads-less builds

[Christian Heimes]

Christian Heimes added the comment:

+1 to restore dummy_threading and go through a proper deprecation phase in 3.7+.

-0 to restore _dummy_thread. It's an internal, private module.

--
nosy: +christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31427] Proposed addition to Windows FAQ

[Steve Dower]

Steve Dower added the comment:

This is a problem with 3.5 and later running on Windows 8.1 or earlier without 
all Windows Updates being installed.

It can happen for two reasons:
* not using the official installer (most common)
* random failure in the official installer (rare)

Installing KB2999226 is a good start, though it will likely trigger another 
Windows Update to get the latest version. Windows 10 is not affected.

I'm in favor of adding this to the FAQ.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25115] SSL_set_verify_depth not exposed by the ssl module

[Alex Gaynor]

Alex Gaynor added the comment:

For the use case of "I want to trust this CA, but I don't want to trust any of 
it's sub CAs" I think there's a simpler solution than expanding our API:

Create your own cross-sign of the root you want, and add a pathLenConstraint: 0 
to the basicConstraints extension.

By create a cross-sign, I mean a new certificate with the same 
subject/SPKI/SKI/other-extensions, but instead of being self-signed, sign it 
under some random private key you throw away. And then use that as your trust 
root, instead of the original certificate.

This should work fine for validation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31432] Documention for CERT_OPTIONAL is misleading

[Christian Heimes]

Christian Heimes added the comment:

PS: OpenSSL still validates the chain when SSL_VERIFY_NONE is set. In that mode 
OpenSSL just does not abort the handshake when an error occurs. OpenSSL keeps 
the last verification error around, see #31372.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31069] test_multiprocessing_spawn and test_multiprocessing_forkserver leak dangling processes

[STINNER Victor]

STINNER Victor added the comment:

On the FreeBSD 10 buildbot, I ran test_multiprocessing_forkserver during 10 
minutes twice in two terminals, while running "./python -m test -j2 -r -F" 
twice in two other terminals to stress the machine. I failed to reproduce the 
"Warning -- Dangling threads: {}" warning.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31395] Docs Downloads are 404s

[Ned Deily]

Ned Deily added the comment:

Thanks for the report.  After looking into this a bit, the URLs you are using 
are those from the daily docs build, the latest doc changes checked into each 
branch.  As best I can tell, the part of the daily build that makes the 
downloadable files has been broken, probably for some time and most likely due 
to trying to use an older version of TeX Live.  Until we can get the server 
upgraded, you can download the docs that reflect the source as of the 3.6.2 
release.  You can find these linked to on the docs download page:

https://www.python.org/doc/versions/

I've reopened the original pythondotorg issue since it turns out to be a server 
issue.

--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31433] Impossible download python 3.6.2 and 2.7 documentation (html)

[Diego Satoba]

New submission from Diego Satoba:

Hi, 

Links to python 3.6.2 and 2.7 documentation in HTML are broken, web server 
returns 404 Not Found.

The links are:
https://docs.python.org/2/archives/python-2.7.14rc1-docs-html.zip
https://docs.python.org/3/archives/python-3.6.2-docs-html.zip

--
messages: 301979
nosy: Diego Satoba
priority: normal
severity: normal
status: open
title: Impossible download python 3.6.2 and 2.7 documentation (html)
type: resource usage
versions: Python 2.7, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31370] Remove support for threads-less builds

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Following lines needs updating:

Lib/importlib/_bootstrap.py:1135
Lib/_pydecimal.py:436
Lib/test/ssl_servers.py:11
Lib/test/support/__init__.py:2053
Lib/test/test_httplib.py:1080
Lib/test/test_idle.py:4
Lib/test/test_multiprocessing_main_handling.py:3
Lib/test/test_thread.py:5
Lib/test/test_threadsignals.py:8
Lib/test/test_tools/test_sundry.py:43
Lib/test/test_winreg.py:7
Lib/test/test_wsgiref.py:256
Lib/test/test_xmlrpc.py:1179

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16500] Allow registering at-fork handlers

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +3511

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31234] Make support.threading_cleanup() stricter

[STINNER Victor]

Changes by STINNER Victor :


--
keywords: +patch
pull_requests: +3510
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31417] Use the enumerate function where appropriate

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31250] test_asyncio leaks dangling threads

[STINNER Victor]

Changes by STINNER Victor :


--
keywords: +patch
pull_requests: +3512
stage: resolved -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30923] Add -Wimplicit-fallthrough=0 to Makefile ?

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +3513

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31275] Check fall-through in _codecs_iso2022.c

[STINNER Victor]

Changes by STINNER Victor :


--
pull_requests: +3514

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31434] [3.6] Python/random.c:128:17: warning: implicit declaration of function 'getrandom'

[STINNER Victor]

New submission from STINNER Victor:

haypo@selma$ touch Python/random.c 
haypo@selma$ LANG= make

gcc -pthread -c -Wno-unused-result -Wsign-compare -g -Og -Wall 
-Wstrict-prototypes -O0   -std=c99 -Wextra -Wno-unused-result 
-Wno-unused-parameter -Wno-missing-field-initializers   -I. -I./Include
-DPy_BUILD_CORE -o Python/random.o Python/random.c
Python/random.c: In function 'py_getrandom':
Python/random.c:128:17: warning: implicit declaration of function 'getrandom'; 
did you mean 'py_getrandom'? [-Wimplicit-function-declaration]
 n = getrandom(dest, n, flags);
 ^
 py_getrandom

--
components: Build
messages: 301981
nosy: haypo
priority: normal
severity: normal
status: open
title: [3.6] Python/random.c:128:17: warning: implicit declaration of function 
'getrandom'
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16500] Allow registering at-fork handlers

[STINNER Victor]

STINNER Victor added the comment:


New changeset a15d155aadfad232158f530278505cdc6f326f93 by Victor Stinner in 
branch 'master':
bpo-31234: Enhance test_thread.test_forkinthread() (#3516)
https://github.com/python/cpython/commit/a15d155aadfad232158f530278505cdc6f326f93


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31234] Make support.threading_cleanup() stricter

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3515

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31234] Make support.threading_cleanup() stricter

[STINNER Victor]

STINNER Victor added the comment:


New changeset a15d155aadfad232158f530278505cdc6f326f93 by Victor Stinner in 
branch 'master':
bpo-31234: Enhance test_thread.test_forkinthread() (#3516)
https://github.com/python/cpython/commit/a15d155aadfad232158f530278505cdc6f326f93


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16500] Allow registering at-fork handlers

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3516

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31434] [3.6] Python/random.c:128:17: warning: implicit declaration of function 'getrandom'

[STINNER Victor]

STINNER Victor added the comment:

Oh, the warning probably comes from the fact that I upgraded since Fedora 24 to 
Fedora 25. Re-running ./configure fixed the issue.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16251] pickle special methods are looked up on the instance rather than the type

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> The two test cases added demonstrate what was impossible to pickle before and 
> is now.

These two classes obviously are not pickleable. Pickling or copying them is a 
programming error. I believe the proper way of making them pickleable and 
copyable is implementing corresponding special methods.

> Can you give me an example where this would lead to incorrect pickle data?

Any class that needs non-trivial __getstate__(). If pickling is failed now it 
means that the class is not pickleable. With your patch pickling can be 
successful, but there is no guarantee that it is correct.

For example, modifying one of your example:

class Proxy:
def __init__(self, proxied_object):
self.proxied_object = proxied_object
self.id = id(proxied_object)
def __getattr__(self, name):
return getattr(self.proxied_object, name)

> This is what `hasattr()` in Python 2 did.  This is why in Python 2 the 
> `RecursionError` example I added to the tests was actually working just fine.

hasattr() is broken in Python 2. It was fixed in Python 3. Your patch 
reintroduces similar bug in copy.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31433] Impossible download python 3.6.2 and 2.7 documentation (html)

[Berker Peksag]

Berker Peksag added the comment:

Thank you for the report. This is a duplicate of issue 31395. See 
https://bugs.python.org/issue31395#msg301978 and 
https://github.com/python/psf-salt/issues/118 for details.

--
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Docs Downloads are 404s
type: resource usage -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31370] Remove support for threads-less builds

[R. David Murray]

R. David Murray added the comment:

dummy_threading should definitely not have been removed, and like all the other 
APIs should not be removed until 2.7 is dead.  Deprecating it is of course fine 
:)

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31370] Remove support for threads-less builds

[R. David Murray]

R. David Murray added the comment:

And actually, I wouldn't be surprised if eventlet depended on the 
*functionality* in _dummy_threading, so you probably need to restore that, too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16251] pickle special methods are looked up on the instance rather than the type

[Łukasz Langa]

Łukasz Langa added the comment:

> These two classes obviously are not pickleable. Pickling or copying them is a 
> programming error.

The recursion case was successfully deep copying under Python 2. When migrating 
the code, the sudden recursion error is pretty hard to debug.


> I believe the proper way of making them pickleable and copyable is 
> implementing corresponding special methods.

Right, but during migration from Python 2 to Python 3 the error message is 
nowhere close suggesting what the correct behavior is.


>> Can you give me an example where this would lead to incorrect pickle data?
> Any class that needs non-trivial __getstate__().

My patch doesn't change anything here. It simply causes special methods to be 
reported as not present instead of raising exceptions from within __getattr__.


> hasattr() is broken in Python 2. It was fixed in Python 3.

Yes, I agree.


> Your patch reintroduces similar bug in copy.

No, my patch introduces a getattr() equivalent for deepcopy which is robust 
against random exceptions raised from __getattr__.





Let's take a step back.  My goal with this patch is two-fold:

* make code that worked on Python 2 (even if clowny) not fail on Python 3, 
adding to the migration burden;

* make a change that is not changing semantics of the current behavior to not 
break existing code deliberately putting magic methods on instances (hence I'm 
not switching to the right behavior to test presence of magic methdos on types 
instead).


Clearly the current workaround I wrote doesn't go in the direction you'd like 
to see.  Do you have a suggestion of an approach that would be better?  I can 
implement it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18875] Idle: Auto insertion of the closing parens, brackets, and braces

[Charles Wohlganger]

Changes by Charles Wohlganger :


--
keywords: +patch
pull_requests: +3517
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16251] pickle special methods are looked up on the instance rather than the type

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> The recursion case was successfully deep copying under Python 2. When
> migrating the code, the sudden recursion error is pretty hard to debug.

Python 3 is not compatible with Python 2 because it fixes many bugs that can't 
be fixed without breaking backward compatibility. This is a one of such cases.

The problem with copying is not the only problem with that class. It also has 
problems when the garbage collector breaks reference loops and sets instance 
attributes to None. The idiomatic ways of solving these problems is accessing 
to proxied_object as self.__dict__['proxied_object'] or setting a class 
attribute proxied_object = None. We had fixed a number of similar issues in the 
stdlib.

> Right, but during migration from Python 2 to Python 3 the error message is
> nowhere close suggesting what the correct behavior is.

I think a traceback should help to identify the problem. At least it looks 
pretty clear to me.

> My patch doesn't change anything here. It simply causes special methods to
> be reported as not present instead of raising exceptions from within
> __getattr__.

And this is a regression change. Instead of not producing incorrect data, the 
code now poduces it.

Yet one drawback is a performance regression. Additional checks slow down a 
copying.

> > Your patch reintroduces similar bug in copy.
> No, my patch introduces a getattr() equivalent for deepcopy which is robust
> against random exceptions raised from __getattr__.

The code shouldn't be tolerant to random exceptions raised from __getattr__. 
Exceptions signal about a bug in user code.

> * make code that worked on Python 2 (even if clowny) not fail on Python 3,
> adding to the migration burden;

Raising an exception is a feature of Python 3, not a bug. It helps to catch 
programming errors in user code.

> Clearly the current workaround I wrote doesn't go in the direction you'd
> like to see.  Do you have a suggestion of an approach that would be better?
>  I can implement it.

The current behavior LGTM. I don't think it needs to be improved.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31435] Addition giving incorrect result in certain circumstances

[Aodhán Collins]

New submission from Aodhán Collins:

Basic addition is dropping a tiny fraction when adding together certain 
numbers. We have discovered that when adding together the numbers 8.95 and 0.95 
we get an incorrect answer, that is off by a tiny fraction. This doesn't occur 
when adding 7.95 and 0.95 but occurs for 8.95 and above. We have attached a 
file showing our calculations failing on Python 2.7 (on both a Mac and Linux 
system) and 3.5 (on a Linux system).

--
components: Interpreter Core
files: pythonbug.txt
messages: 301991
nosy: Aodhán Collins
priority: normal
severity: normal
status: open
title: Addition giving incorrect result in certain circumstances
type: behavior
versions: Python 3.5
Added file: https://bugs.python.org/file47136/pythonbug.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31435] Addition giving incorrect result in certain circumstances

[Stefan Krah]

Stefan Krah added the comment:

Pythons has binary floating point, which does not give the same
results as a pocket calculator.

You can see the differences by using the decimal module:


# These are the binary floats in exact decimal representation.
>>> Decimal(7.95)
Decimal('7.95017763568394002504646778106689453125')
>>> Decimal(8.95)
Decimal('8.949289457264239899814128875732421875')


# This is exact decimal arithmetic.
>>> Decimal("8.95") + Decimal("0.95")
Decimal('9.90')

--
nosy: +skrah
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31435] Addition giving incorrect result in certain circumstances

[R. David Murray]

R. David Murray added the comment:

https://docs.python.org/3/tutorial/floatingpoint.html

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31427] Proposed addition to Windows FAQ

[Eryk Sun]

Changes by Eryk Sun :


--
versions: +Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31250] test_asyncio leaks dangling threads

[STINNER Victor]

STINNER Victor added the comment:


New changeset 5013a5ebc9978a58435036fa3860c465882c21da by Victor Stinner in 
branch '3.6':
[3.6] bpo-31250: test_asyncio: fix dangling threads (#3517)
https://github.com/python/cpython/commit/5013a5ebc9978a58435036fa3860c465882c21da


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31427] Proposed addition to Windows FAQ

[Eryk Sun]

Eryk Sun added the comment:

The FAQ could instead link to the more recent update, KB3118401.

https://support.microsoft.com/en-us/help/3118401/update-for-universal-c-runtime-in-windows

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31250] test_asyncio leaks dangling threads

[STINNER Victor]

Changes by STINNER Victor :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27815] Make SSL suppress_ragged_eofs default more secure

[Martin Panter]

Martin Panter added the comment:

Even if some use cases depend on suppress_ragged_eofs=True, I think it is best 
to avoid that as the default. There could be a deprecation period if necessary.

I tested some HTTP clients I had handy. In summary, most seemed to handle a 
truncation attack on the Set-Cookie field sensibly (but Python is vulnerable 
without my patch or other solution). On the other hand, all the clients I tried 
handled one case of an insecurely-truncated body the same as a normal EOF 
(while I propose to treat this as an error).

The clients I tested: Firefox/46.0, curl/7.43.0, Wget/1.13.4, Links 2.12, 
ELinks/0.13.GIT, Python-urllib/3.5 (unpatched), and Python-urllib/3.7 with my 
patch. I tried three test cases:

1. Truncate Set-Cookie field, with no terminating newline. The client should 
not accept the cookie, in case an attribute such as “Secure” was removed, like 
in .
>>> c.sendall(b"Set-Cookie: COOKIE=meant-to-be-Secure")
>>> c.shutdown(SHUT_RDWR)

Python (unpatched) treats the Set-Cookie field as valid. It appears in the 
HTTPResponse object, with no clue that it was truncated. Wget was also 
vulnerable. Firefox and Curl did not record the cookie, but did not indicate 
any error either. Links does not support cookies, while Elinks tried 3 times 
and reported an error.

2. Content-Length response with truncated text/html. IMO a client should inform 
the user that the response was cut off (with or without SSL), but sometimes the 
user may want to see the first half of the response anyway.
>>> c.sendall(b"Content-Length: 100\r\n\r\n" b"Truncat")
>>> c.shutdown(SHUT_RDWR)

Curl, wget, Links and Elinks all outputted the incomplete response, and 
reported an error. Firefox displayed the truncated page without indicating any 
error. In most cases, Python raised an IncompleteRead exception, but it 
depended on the pattern of read calls, and some or all of the truncated data 
was hidden in the undocumented “IncompleteRead.partial” attribute.

3. “Connection: close” response with truncated HTML:
>>> c.sendall(b"Connection: close\r\n\r\n" b"Truncat")
>>> c.shutdown(SHUT_RDWR)

This is the case where all the clients (other than my patched Python) treated 
this like a valid non-truncated response. But IMO in general it should be dealt 
with like the Content-Length case if the SSL level wasn’t shut down properly.

Victor: Sorry, I’m unlikely to make a Git Hub pull request any time soon, but I 
don’t mind if someone else does.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28909] Adding LTTng-UST tracing support

[Francis Deslauriers]

Francis Deslauriers added the comment:

Hi all,
Is there anything I can do to move this patch-set forward?

@Charalampos, I will make sure to include this in the patch. Thank you.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31436] test_socket.SendfileUsingSendfileTest.testWithTimeoutTriggeredSend fails due to sendfile completing before timeout

[Brian Moyles]

New submission from Brian Moyles:

In building Python 3.6.2 on Ubuntu 16.04, test_socket repeatedly fails at
==
FAIL: testWithTimeoutTriggeredSend (test.test_socket.SendfileUsingSendfileTest)
--
Traceback (most recent call last):
  File "/mnt/python/Python-3.6.2/Lib/test/test_socket.py", line 277, in 
_tearDown
raise exc
  File "/mnt/python/Python-3.6.2/Lib/test/test_socket.py", line 295, in 
clientRun
test_func()
  File "/mnt/python/Python-3.6.2/Lib/test/test_socket.py", line 5358, in 
_testWithTimeoutTriggeredSend
self.assertRaises(socket.timeout, meth, file)
AssertionError: timeout not raised by _sendfile_use_sendfile

--

It appears this is failing as _sendfile_use_sendfile completes before the 0.01s 
timeout set in _testWithTimeoutTriggeredSend

Adjusting FILESIZE in class SendfileUsingSendTest to 100MB instead of 10MB (or 
creating FILESIZE on class SendfileUsingSendfileTest so only that set of tests 
uses a 100MB file) succeeds.

issue17085 was a similar bug from a few years ago but I'm not sure that this 
can or should be solved in the same way...

--
components: Tests
messages: 301998
nosy: bmoyles
priority: normal
severity: normal
status: open
title: test_socket.SendfileUsingSendfileTest.testWithTimeoutTriggeredSend fails 
due to sendfile completing before timeout
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31437] test_socket.SendfileUsingSendfileTest.testWithTimeoutTriggeredSend fails due to sendfile completing before timeout

[Brian Moyles]

New submission from Brian Moyles:

In building Python 3.6.2 on Ubuntu 16.04, test_socket repeatedly fails at
==
FAIL: testWithTimeoutTriggeredSend (test.test_socket.SendfileUsingSendfileTest)
--
Traceback (most recent call last):
  File "/mnt/python/Python-3.6.2/Lib/test/test_socket.py", line 277, in 
_tearDown
raise exc
  File "/mnt/python/Python-3.6.2/Lib/test/test_socket.py", line 295, in 
clientRun
test_func()
  File "/mnt/python/Python-3.6.2/Lib/test/test_socket.py", line 5358, in 
_testWithTimeoutTriggeredSend
self.assertRaises(socket.timeout, meth, file)
AssertionError: timeout not raised by _sendfile_use_sendfile

--

It appears this is failing as _sendfile_use_sendfile completes before the 0.01s 
timeout set in _testWithTimeoutTriggeredSend

Adjusting FILESIZE in class SendfileUsingSendTest to 100MB instead of 10MB (or 
creating FILESIZE on class SendfileUsingSendfileTest so only that set of tests 
uses a 100MB file) succeeds.

issue17085 was a similar bug from a few years ago but I'm not sure that this 
can or should be solved in the same way...

--
components: Tests
messages: 301999
nosy: bmoyles
priority: normal
severity: normal
status: open
title: test_socket.SendfileUsingSendfileTest.testWithTimeoutTriggeredSend fails 
due to sendfile completing before timeout
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31437] test_socket.SendfileUsingSendfileTest.testWithTimeoutTriggeredSend fails due to sendfile completing before timeout

[Brian Moyles]

Brian Moyles added the comment:

accidental double-submit, duplicates Issue31436

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31404] undefined behavior and crashes in case of a bad sys.modules

[Eric Snow]

Eric Snow added the comment:

> I haven't finished reviewing PR 1638. I'm not sure that this change
> is worth. It breaks a code that assumes that sys.module is a dict,
> and I afraid it slows down importing. Maybe revert this change until
> resolving all problems?

Yeah, I'm leaning that way myself.  I'll take another look later today or 
tomorrow.  FWIW, the likelihood of this causing problems to actual users is 
extremely low, so the urgency to fix this isn't high.  Still, I don't want this 
to linger.

As I said before, ideally we would prevent non-mappings from getting assigned 
to sys.modules.  One alternative would be to introduce sys.__modules__ and fall 
back to it if sys.modules is invalid.

--
nosy: +brett.cannon, ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29475] option to not follow symlinks when globbing

[wim glenn]

wim glenn added the comment:

+1, would like to use this feature too, and I would like it also in 
pathlib.PosixPath.glob

--
nosy: +wim.glenn

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30923] Add -Wimplicit-fallthrough=0 to Makefile ?

[STINNER Victor]

STINNER Victor added the comment:


New changeset c0e77364ca29df6cfb311e79892955c92bd8e595 by Victor Stinner in 
branch '3.6':
[3.6] bpo-30923: Silence fall-through warnings included in -Wextra since 
gcc-7.0 (#3518)
https://github.com/python/cpython/commit/c0e77364ca29df6cfb311e79892955c92bd8e595


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31275] Check fall-through in _codecs_iso2022.c

[STINNER Victor]

STINNER Victor added the comment:


New changeset c0e77364ca29df6cfb311e79892955c92bd8e595 by Victor Stinner in 
branch '3.6':
[3.6] bpo-30923: Silence fall-through warnings included in -Wextra since 
gcc-7.0 (#3518)
https://github.com/python/cpython/commit/c0e77364ca29df6cfb311e79892955c92bd8e595


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16500] Allow registering at-fork handlers

[STINNER Victor]

STINNER Victor added the comment:


New changeset bcf042ff98b6261b7780c1e40fa1681ef30502f9 by Victor Stinner (Miss 
Islington (bot)) in branch '3.6':
[3.6] bpo-31234: Enhance test_thread.test_forkinthread() (GH-3516) (#3519)
https://github.com/python/cpython/commit/bcf042ff98b6261b7780c1e40fa1681ef30502f9


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31234] Make support.threading_cleanup() stricter

[STINNER Victor]

STINNER Victor added the comment:


New changeset bcf042ff98b6261b7780c1e40fa1681ef30502f9 by Victor Stinner (Miss 
Islington (bot)) in branch '3.6':
[3.6] bpo-31234: Enhance test_thread.test_forkinthread() (GH-3516) (#3519)
https://github.com/python/cpython/commit/bcf042ff98b6261b7780c1e40fa1681ef30502f9


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31275] Check fall-through in _codecs_iso2022.c

[STINNER Victor]

Changes by STINNER Victor :


--
versions: +Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31249] test_concurrent_futures leaks dangling threads

[STINNER Victor]

STINNER Victor added the comment:

I still see the warning sometimes:

0:04:09 load avg: 7.03 [185/405/1] test_concurrent_futures failed (env changed) 
(68 sec) -- running: test_multiprocessing_spawn (160 sec), test_gdb (53 sec), 
test_lib2to3 (195 sec)
test_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_cancelled (test.test_concurrent_futures.FutureTests) ... ok
test_done (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_cancelled (test.test_concurrent_futures.FutureTests) 
... ok
test_done_callback_already_failed (test.test_concurrent_futures.FutureTests) 
... ok
test_done_callback_already_successful 
(test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_raises (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_exception (test.test_concurrent_futures.FutureTests) 
... ok
test_done_callback_with_result (test.test_concurrent_futures.FutureTests) ... ok
test_exception_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_exception_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_repr (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_running (test.test_concurrent_futures.FutureTests) ... ok
test_correct_timeout_exception_msg 
(test.test_concurrent_futures.ProcessPoolAsCompletedTests) ... 0.15s ok
test_duplicate_futures 
(test.test_concurrent_futures.ProcessPoolAsCompletedTests) ... 2.16s ok
test_free_reference_yielded_future 
(test.test_concurrent_futures.ProcessPoolAsCompletedTests) ... 0.15s ok
test_no_timeout (test.test_concurrent_futures.ProcessPoolAsCompletedTests) ... 
0.15s ok
test_zero_timeout (test.test_concurrent_futures.ProcessPoolAsCompletedTests) 
... 2.15s ok
test_free_reference (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 
0.17s ok
test_killed_child (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 
0.15s ok
test_map (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 0.18s ok
test_map_chunksize (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 
0.17s ok
test_map_exception (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 
0.17s ok
test_map_timeout (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 
6.16s ok
test_max_workers_negative 
(test.test_concurrent_futures.ProcessPoolExecutorTest) ... 0.14s ok
test_no_stale_references (test.test_concurrent_futures.ProcessPoolExecutorTest) 
... 0.14s ok
test_shutdown_race_issue12456 
(test.test_concurrent_futures.ProcessPoolExecutorTest) ... 0.15s ok
test_submit (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 0.14s ok
test_submit_keyword (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 
0.13s ok
test_traceback (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 0.15s 
ok
test_context_manager_shutdown 
(test.test_concurrent_futures.ProcessPoolShutdownTest) ... 0.07s ok
test_del_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) ... 
0.05s Warning -- threading_cleanup() detected 1 leaked threads (count: 1, 
dangling: 2)
ok
test_hang_issue12364 (test.test_concurrent_futures.ProcessPoolShutdownTest) ... 
1.09s ok
test_interpreter_shutdown 
(test.test_concurrent_futures.ProcessPoolShutdownTest) ... 2.67s ok
test_processes_terminate (test.test_concurrent_futures.ProcessPoolShutdownTest) 
... 0.05s ok
test_run_after_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) 
... 0.00s ok
test_all_completed (test.test_concurrent_futures.ProcessPoolWaitTests) ... 
0.16s ok
test_first_completed (test.test_concurrent_futures.ProcessPoolWaitTests) ... 
1.64s ok
test_first_completed_some_already_completed 
(test.test_concurrent_futures.ProcessPoolWaitTests) ... 1.65s ok
test_first_exception (test.test_concurrent_futures.ProcessPoolWaitTests) ... 
3.15s ok
test_first_exception_one_already_failed 
(test.test_concurrent_futures.ProcessPoolWaitTests) ... 2.15s ok
test_first_exception_some_already_complete 
(test.test_concurrent_futures.ProcessPoolWaitTests) ... 1.65s ok
test_timeout (test.test_concurrent_futures.ProcessPoolWaitTests) ... 6.15s ok
test_correct_timeout_exception_msg 
(test.test_concurrent_futures.ThreadPoolAsCompletedTests) ... 0.16s ok
test_duplicate_futures 
(test.test_concurrent_futures.ThreadPoolAsCompletedTests) ... 2.15s ok
test_free_reference_yielded_future 
(test.test_concurrent_futures.ThreadPoolAsCompletedTests) ... 0.15s ok
test_no_timeout (test.test_concurrent_futures.ThreadPoolAsCompletedTests) ... 
0.16s ok
test_zero_timeout (test.test_concurrent_futures.ThreadPoolAsCompletedTests) ... 
2.15s ok
test_default_workers (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 
0.15s ok
test_free_reference (test.test_concurrent_f

[issue31249] test_concurrent_futures leaks dangling threads

[STINNER Victor]

Changes by STINNER Victor :


--
keywords: +patch
pull_requests: +3519
stage: resolved -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31233] socketserver.ThreadingMixIn leaks running threads after server_close()

[STINNER Victor]

STINNER Victor added the comment:

Another recent example while testing bpo-31234:

test_ThreadingUDPServer (test.test_socketserver.SocketServerTest) ...
(...)
done
Warning -- threading_cleanup() detected 1 leaked threads (count: 1, dangling: 2)
ok

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31234] Make support.threading_cleanup() stricter

[STINNER Victor]

STINNER Victor added the comment:

Remaining issue: socketserver. bpo-31233: socketserver.ThreadingMixIn leaks 
running threads after server_close()

See also bpo-31151: socketserver.ForkingMixIn.server_close() leaks zombie 
processes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31233] socketserver.ThreadingMixIn leaks running threads after server_close()

[STINNER Victor]

STINNER Victor added the comment:

Multiple test_logging tests have been skipped until this issue is fixed: see 
bpo-30830 and commit 6966960468327c958b03391f71f24986bd697307.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31249] test_concurrent_futures leaks dangling threads

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3520

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com