Matěj Stuchlík added the comment:
+1 from the Python team from Fedora, the patch looks good from downstream
standpoint.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23968
Changes by Matěj Stuchlík matej.stuch...@gmail.com:
--
nosy: +sYnfo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23968
___
___
Python-bugs-list
Changes by Matěj Stuchlík matej.stuch...@gmail.com:
--
nosy: +sYnfo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23700
___
___
Python-bugs-list
Changes by Matěj Stuchlík matej.stuch...@gmail.com:
--
nosy: +sYnfo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23420
___
___
Python-bugs-list
Changes by Matěj Stuchlík matej.stuch...@gmail.com:
--
nosy: +sYnfo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23433
___
___
Python-bugs-list
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
Changes by Matěj Stuchlík matej.stuch...@gmail.com:
--
nosy: +sYnfo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23249
___
___
Python-bugs-list
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
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 rep...@bugs.python.org
http://bugs.python.org/issue22327
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 rep...@bugs.python.org
http
Matěj Stuchlík added the comment:
There's no longer any suspicion, no, at least from my side.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18709
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
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
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 rep...@bugs.python.org
http
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
Matěj Stuchlík added the comment:
That seems to be it, no more leaking! Good job!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18913
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
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
New submission from Matěj Stuchlík:
Traceback (most recent call last):
File stdin, line 1, in module
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
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
20 matches
Mail list logo
