[issue11866] race condition in threading._newname()
Peter Saveliev added the comment: Any news? I hope, the change is trivial enough… -- ___ Python tracker <http://bugs.python.org/issue11866> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11866] race condition in threading._newname()
Peter Saveliev added the comment: counter.next() is a C routine and it is atomic from Python's point of view — if I understand right. The test shows that original threading.py leads to a (rare) race here, while with counter object there is no race condition. -- ___ Python tracker <http://bugs.python.org/issue11866> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11866] race condition in threading._newname()
New submission from Peter Saveliev :
The _newname() function has no locking.
It is called from the new thread constructor. Such constructor is executed
within parent thread. So, when several threads create new threads
simultaneously, there can be race condition, leading to the same name for two
(or even more) threads.
8<
>>> import threading
>>> import dis
>>> dis.dis(threading._newname)
403 0 LOAD_GLOBAL 0 (_counter)
3 LOAD_CONST 1 (1)
6 BINARY_ADD
7 STORE_GLOBAL 0 (_counter)
404 10 LOAD_FAST0 (template)
13 LOAD_GLOBAL 0 (_counter)
16 BINARY_MODULO
17 RETURN_VALUE
>>>
8<
The race condition can be achieved between BINARY_ADD and STORE_GLOBAL. Several
threads can do BINARY_ADD before the first one will do STORE_GLOBAL. All racing
threads will get the same name.
8<
$ for i in `seq 0 100`; do python thread_test.py |\
awk -F Thread- '{print $2}' |\
grep -vE '^$' |\
sort |\
uniq -c -d; done
2 35
2 12
...
8<
As you see, there are cases when several threads can get same name.
Proposals: use thread-safe increment counter (with atomic get-increment) like
itertools.counter() (that does not release GIL)
--
components: Extension Modules
files: thread_test.py
messages: 133963
nosy: Peter.Saveliev
priority: normal
severity: normal
status: open
title: race condition in threading._newname()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file21704/thread_test.py
___
Python tracker
<http://bugs.python.org/issue11866>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11866] race condition in threading._newname()
Peter Saveliev added the comment: Ok, patch attached. Patch made for Python: 2.6 Tested Python versions: 2.6, 2.7 -- keywords: +patch versions: +Python 2.6 Added file: http://bugs.python.org/file21866/newname_race_fix.patch ___ Python tracker <http://bugs.python.org/issue11866> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17918] failed incoming SSL connection stays open forever
New submission from Peter Saveliev: Important: only Python2 versions are affected. Python3 works OK. Possibly related issue: http://bugs.python.org/issue12378 (differs: see the line above) Having a server with SSLSocket waiting for connections, the incoming connection, failed on automatic do_handshake(), stays open forever — accept() raises the SSLError and does not return client connection socket. Steps to reproduce == server side: 1. create a SOCK_STREAM socket 2. wrap it with wrap_socket() 3. listen() 4. accept() client side: 1. telnet to this port 2. enter any random text How reproducible In all 146% Expected results 1. Incoming connection is closed and client disconnected Actual results == 1. On the server side, due to exception, the reference to the incoming connection gets lost. 2. The client stays connected as long as the server operates. -- files: ssl_handshake_testcase.py messages: 188544 nosy: Peter.Saveliev priority: normal severity: normal status: open title: failed incoming SSL connection stays open forever type: resource usage versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file30150/ssl_handshake_testcase.py ___ Python tracker <http://bugs.python.org/issue17918> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17918] failed incoming SSL connection stays open forever
Peter Saveliev added the comment: Possible solution would be something like that in SSLSocket.do_handshake(): try: self._sslobj.do_handshake() except SSLError as e: # or even any Exception? self._sock.close() raise e -- ___ Python tracker <http://bugs.python.org/issue17918> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
