[issue46464] concurrent.futures.ProcessPoolExecutor can deadlock when tcmalloc is used
New submission from Yilei Yang :
When Python is built and linked with tcmalloc, using ProcessPoolExecutor may
deadlock. Here is a reproducible example:
$ cat t.py
from concurrent import futures
import sys
def work(iteration, item):
sys.stdout.write(f'working: iteration={iteration}, item={item}\n')
sys.stdout.flush()
for i in range(0, 1):
with futures.ProcessPoolExecutor(max_workers=2) as executor:
executor.submit(work, i, 1)
executor.submit(work, i, 2)
$ python t.py
working: iteration=0, item=1
working: iteration=0, item=2
working: iteration=1, item=1
working: iteration=1, item=2
...
working: iteration=3631, item=1
working: iteration=3631, item=2
The child process fails to finish. It's more likely to reproduce when the
system is busy.
With some bisect search internally, this commit
https://github.com/python/cpython/commit/1ac6e379297cc1cf8acf6c1b011fccc7b3da2cbe
"triggered" the deadlock threshold with tcmalloc.
--
components: Library (Lib)
messages: 411208
nosy: yilei
priority: normal
severity: normal
status: open
title: concurrent.futures.ProcessPoolExecutor can deadlock when tcmalloc is used
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46464>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46525] datetime.timestamp() lose precision when the time is too large
New submission from Yilei Yang : Examples: >>> datetime.datetime(, 1, 1, microsecond=99).timestamp() 7952371200.99 >>> datetime.datetime(, 1, 1, microsecond=99).timestamp() 43012195201.0 >>> datetime.datetime(2567, 1, 1, microsecond=98).timestamp() 18839548800.96 I believe this is an issue caused by using `double` in the C implementation. -- components: Library (Lib) messages: 411676 nosy: yilei priority: normal severity: normal status: open title: datetime.timestamp() lose precision when the time is too large type: behavior versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46784] Duplicated symbols when linking embedded Python with libexpat
New submission from Yilei Yang : The libexpat 2.4.1 upgrade from https://bugs.python.org/issue44394 introduced the following new exported symbols: testingAccountingGetCountBytesDirect testingAccountingGetCountBytesIndirect unsignedCharToPrintable XML_SetBillionLaughsAttackProtectionActivationThreshold XML_SetBillionLaughsAttackProtectionMaximumAmplification We need to adjust Modules/expat/pyexpatns.h (The newer libexpat upgrade https://bugs.python.org/issue46400 has no new symbols). I'll send a PR. -- components: XML messages: 413464 nosy: yilei priority: normal severity: normal status: open title: Duplicated symbols when linking embedded Python with libexpat versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46784> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46784] Duplicated symbols when linking embedded Python with libexpat
Change by Yilei Yang : -- keywords: +patch pull_requests: +29540 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31397 ___ Python tracker <https://bugs.python.org/issue46784> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46899] use of uninitialized value with msan from subprocess_fork_exec
New submission from Yilei Yang : The uid & gid variable from https://github.com/python/cpython/blob/9833bb91e4d5c2606421d9ec2085f5c2dfb6f72c/Modules/_posixsubprocess.c#L737-L738 can be passed to the `do_fork_exec` call below uninitialized and cause msan to report use-of-uninitialized-value errors. Those variables are guarded by call_setgid/call_setuid so they aren't really used uninitialized in practice. It would just be great if we can make it msan clean. Ideally, the long list of do_fork_exec arguments could also be rewritten in a struct. -- components: Library (Lib) messages: 414320 nosy: gregory.p.smith, yilei priority: normal severity: normal status: open title: use of uninitialized value with msan from subprocess_fork_exec type: enhancement versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46899> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42186] unittest overrides more serious warnings filter added before unittest.main()
New submission from Yilei Yang :
Because unittest adds a `default` filter before tests run, other warnings
filters are overridden if added before.
Ideally, unittest should not make the warnings less serious, e.g. if there is
already an 'error' filter that raises exception, it shouldn't "downgrade" to
'default' that simply prints.
The following example, using lib.a_function() raises exception in a regular
program, but the unit test passes:
$ cat lib.py
import warnings
class MyWarning(UserWarning):
pass
warnings.filterwarnings('error', category=MyWarning)
def a_function():
warnings.warn('Do not use.', MyWarning)
$ cat lib_test.py
import unittest
import lib
class TestLib(unittest.TestCase):
def test_function(self):
lib.a_function()
if __name__ == '__main__':
unittest.main()
$ python -m unittest -v lib_test
test_function (lib_test.TestLib) ... lib.py:6: MyWarning: Do not use.
warnings.warn('Do not use.', MyWarning)
ok
--
Ran 1 test in 0.000s
OK
$ python
>>> import lib
>>> lib.a_function()
Traceback (most recent call last):
File "", line 1, in
File "lib.py", line 6, in a_function
warnings.warn('Do not use.', MyWarning)
lib.MyWarning: Do not use.
--
components: Library (Lib)
messages: 379843
nosy: yilei
priority: normal
severity: normal
status: open
title: unittest overrides more serious warnings filter added before
unittest.main()
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42186>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21149] logging._removeHandlerRef is not threadsafe during interpreter shutdown
Yilei Yang added the comment: Here is a minimal example: main.py: from pkg_a import lib_a pkg_a/__init__.py pkg_a/lib_a.py import logging import sys import pkg_a # This is important handler = logging.StreamHandler(sys.stderr) It does not happen in Python 3 though (3.5.3 at least). -- nosy: +yileiyang ___ Python tracker <https://bugs.python.org/issue21149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
