[issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET)
Matěj Stuchlík added the comment: +1 from the Python team from Fedora, the patch looks good from downstream standpoint. -- ___ Python tracker <http://bugs.python.org/issue23968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET)
Changes by Matěj Stuchlík : -- nosy: +sYnfo ___ Python tracker <http://bugs.python.org/issue23968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23700] tempfile.NamedTemporaryFile can close too early if used as iterator
Changes by Matěj Stuchlík : -- nosy: +sYnfo ___ Python tracker <http://bugs.python.org/issue23700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23420] python -m cProfile -s fails with non informative message
Changes by Matěj Stuchlík : -- nosy: +sYnfo ___ Python tracker <http://bugs.python.org/issue23420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23433] undefined behaviour in faulthandler.c, exposed by GCC 5
Matěj Stuchlík added the comment: FWIW with your patch all the tests pass on Fedora rawhide in Koji [1], whereas before the x86_64 build would hang [2]. If you want to do some more testing, you can download the rpms from [1]. :) [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=8894494 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=8893808 -- ___ Python tracker <http://bugs.python.org/issue23433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23433] undefined behaviour in faulthandler.c, exposed by GCC 5
Changes by Matěj Stuchlík : -- nosy: +sYnfo ___ Python tracker <http://bugs.python.org/issue23433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23249] test_win32 fails on aarch64
Changes by Matěj Stuchlík : -- nosy: +sYnfo ___ Python tracker <http://bugs.python.org/issue23249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22327] test_gdb failures on Ubuntu 14.10
Matěj Stuchlík added the comment: While with Python3.5's test_gdb does fail when building in Koji [0], it seems to pass fine in our other build system - Copr [1]. Comparing the two [2][3], it seems the only big difference is the kernel version - 2.6.32 in Copr and 3.16.3 in Koji. Not sure how relevant this is, just something I noticed. [0] https://kojipkgs.fedoraproject.org//work/tasks/700/7810700/build.log [1] http://copr-be.cloud.fedoraproject.org/results/churchyard/python3-nightly/fedora-21-i386/python3-3.5.0-0.117.20141009hgf7124c167603.fc20/build.log [2] https://kojipkgs.fedoraproject.org//work/tasks/700/7810700/root.log [3] http://copr-be.cloud.fedoraproject.org/results/churchyard/python3-nightly/fedora-21-i386/python3-3.5.0-0.117.20141009hgf7124c167603.fc20/root.log -- ___ Python tracker <http://bugs.python.org/issue22327> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22327] test_gdb failures on Ubuntu 14.10
Matěj Stuchlík added the comment: FYI I'm seeing the error with the new 3.4.2 release as well. https://kojipkgs.fedoraproject.org//work/tasks/599/7800599/build.log -- ___ Python tracker <http://bugs.python.org/issue22327> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22327] test_gdb failures on Ubuntu 14.10
Matěj Stuchlík added the comment: Suddenly started to see the same error on Fedora rawhide [0]. [0] https://kojipkgs.fedoraproject.org//work/tasks/3551/7773551/build.log -- nosy: +sYnfo ___ Python tracker <http://bugs.python.org/issue22327> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)
Matěj Stuchlík added the comment: There's no longer any suspicion, no, at least from my side. -- ___ Python tracker <http://bugs.python.org/issue18709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18913] ssl._ssl._test_decode_cert seems to leak memory with certain certificates in Python 2.6
Matěj Stuchlík added the comment: That seems to be it, no more leaking! Good job! -- ___ Python tracker <http://bugs.python.org/issue18913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18913] ssl._ssl._test_decode_cert seems to leak memory with certain certificates in Python 2.6
Matěj Stuchlík added the comment: Potentially interesting part of the valgrind output: ==21685== 42,400 (3,200 direct, 39,200 indirect) bytes in 100 blocks are definitely lost in loss record 909 of 914 ==21685==at 0x4A0887C: malloc (vg_replace_malloc.c:270) ==21685==by 0x331B06315F: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.1e) ==21685==by 0x331B0CD4EE: sk_new (in /usr/lib64/libcrypto.so.1.0.1e) ==21685==by 0x331B0F2E42: ??? (in /usr/lib64/libcrypto.so.1.0.1e) ==21685==by 0x331B0F2F7B: ??? (in /usr/lib64/libcrypto.so.1.0.1e) ==21685==by 0x331B0F2884: ASN1_item_ex_d2i (in /usr/lib64/libcrypto.so.1.0.1e) ==21685==by 0x331B0F3103: ASN1_item_d2i (in /usr/lib64/libcrypto.so.1.0.1e) ==21685==by 0xB431892: _decode_certificate (_ssl.c:710) ==21685==by 0xB431E57: PySSL_test_decode_certificate (_ssl.c:1025) ==21685==by 0x49D187: PyEval_EvalFrameEx (ceval.c:3750) ==21685==by 0x497A01: PyEval_EvalCodeEx (ceval.c:3000) ==21685==by 0x497B41: PyEval_EvalCode (ceval.c:541) _ssl.c:710 snippet: (...) p = ext->value->data; if (method->it) > names = (GENERAL_NAMES*) (ASN1_item_d2i(NULL, &p, ext->value->length, > ASN1_ITEM_ptr(method->it))); else names = (GENERAL_NAMES*) (method->d2i(NULL, &p, ext->value->length)); (...) -- ___ Python tracker <http://bugs.python.org/issue18913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18913] ssl._ssl._test_decode_cert seems to leak memory with certain certificates in Python 2.6
Matěj Stuchlík added the comment: Ah, that is unfortunate. I did check it for 2.7 and 3.4, neither of those leak, I can check it for the rest tomorrow, but I imagine it'll be the same story. -- ___ Python tracker <http://bugs.python.org/issue18913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18913] ssl._ssl._test_decode_cert seems to leak memory with certain certificates in Python 2.6
Matěj Stuchlík added the comment: That's a good idea: NULLBYTECERT = os.path.join(os.path.dirname(__file__) or os.curdir, "nullbytecert.pem") for i in xrange(100): p = ssl._ssl._test_decode_cert(NULLBYTECERT) gives ==1647== LEAK SUMMARY: ==1647==definitely lost: 3,200 bytes in 100 blocks ==1647==indirectly lost: 39,200 bytes in 1,600 blocks ==1647== possibly lost: 591,285 bytes in 545 blocks ==1647==still reachable: 1,955,652 bytes in 3,136 blocks ==1647== suppressed: 0 bytes in 0 blocks so yes, they do increase. -- ___ Python tracker <http://bugs.python.org/issue18913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18913] ssl._ssl._test_decode_cert seems to leak memory with certain certificates in Python 2.6
New submission from Matěj Stuchlík: Doing 'valgrind --suppressions=Misc/valgrind-python.supp ./python Lib/tests/test_ssl.py' I'm getting: ==322== LEAK SUMMARY: ==322==definitely lost: 32 bytes in 1 blocks ==322==indirectly lost: 392 bytes in 16 blocks ==322== possibly lost: 1,617,191 bytes in 1,052 blocks ==322==still reachable: 4,068,239 bytes in 3,201 blocks ==322== suppressed: 0 bytes in 0 blocks I managed to reduce that to a shorter reproducer: """ import os import ssl NULLBYTECERT = os.path.join(os.path.dirname(__file__) or os.curdir, "nullbytecert.pem") p = ssl._ssl._test_decode_cert(NULLBYTECERT) """ where NULLBYTECERT is the cert introduced in issue18709. Python 2.7 does not leak like this, and the PySSL_test_decode_certificate function looks the same there as in Python 2.6, so I assume it's something else that does the actual leaking. -- components: Extension Modules messages: 196837 nosy: sYnfo priority: normal severity: normal status: open title: ssl._ssl._test_decode_cert seems to leak memory with certain certificates in Python 2.6 type: resource usage versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue18913> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)
Matěj Stuchlík added the comment: Oh, I only checked the particular commit that fixed this issue in 2.6 (50803d881a92). I am not getting any leaks in 2.6 tip either, so I guess it was fixed somewhere along the way. Sorry for the confusion! -- ___ Python tracker <http://bugs.python.org/issue18709> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)
Matěj Stuchlík added the comment: Doing 'valgrind --suppressions=valgrind-python.supp ./python Lib/tests/regrtest.py test_ssl.py' I'm getting ==11944== LEAK SUMMARY: ==11944==definitely lost: 32 bytes in 1 blocks ==11944==indirectly lost: 392 bytes in 16 blocks ==11944== possibly lost: 27,008 bytes in 58 blocks ==11944==still reachable: 4,267,092 bytes in 4,124 blocks ==11944== suppressed: 32 bytes in 1 blocks and as far as I can tell the leak is introduced by this patch, I can't seem to figure out what could be causing it though. -- nosy: +sYnfo ___ Python tracker <http://bugs.python.org/issue18709> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18540] imaplib.IMAP4() ends with "Name or service not known" on Fedora 18
Matěj Stuchlík added the comment: >So this represents a change in behavior of the socket library on Fedora 18 vs >earlier versions? I don't believe so. This happens on my Fedora 18 system, my Debian box with Python 2.6.6, on Fedora 19 (https://bugzilla.redhat.com/show_bug.cgi?id=987340), another Debian system (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591471) and python compiled from the default branch does the same thing. The documentation for imaplib.IMAP4 says: "If host is not specified, '' (the local host) is used." My point is that imaplib.IMAP4 without any arguments should try to connect to localhost, however this is not what is currently happening, at least on the systems mentioned above. Why I think this is happening I've tried to explain in my previous comment. >Do any of the impalib tests fail? Nope. -- ___ Python tracker <http://bugs.python.org/issue18540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18540] imaplib.IMAP4() ends with "Name or service not known" on Fedora 18
New submission from Matěj Stuchlík: Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python2.7/imaplib.py", line 163, in __init__ self.open(host, port) File "/usr/lib64/python2.7/imaplib.py", line 229, in open self.sock = socket.create_connection((host, port)) File "/usr/lib64/python2.7/socket.py", line 553, in create_connection for res in getaddrinfo(host, port, 0, SOCK_STREAM): socket.gaierror: [Errno -2] Name or service not known Steps to Reproduce: 1. run python interpreter 2. import imaplib 3. imaplib.IMAP4() Expected behavior would be, as per documentation, for imaplib to try to connect to localhost. The root cause is, I believe, this: socket.py::create_connection states "An host of '' [...] tells the OS to use the default." and thus imaplib uses '' as the default value for host, however from getaddrinfo (to which function the host variable is passed) documentation and source it seems to me that it expect None, not '' as the default value. Substituting '' for None as the default value for host in imaplib.py seems to resolve this issue, I've included a tentative patch that does just that. In case this will need patching I'd be more than happy to work on a more complete patch! :) -- components: Library (Lib) files: imaplib.patch keywords: patch messages: 193632 nosy: sYnfo priority: normal severity: normal status: open title: imaplib.IMAP4() ends with "Name or service not known" on Fedora 18 type: behavior versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file31027/imaplib.patch ___ Python tracker <http://bugs.python.org/issue18540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
