Thomas Herve added the comment:
FWIW, we encountered roughly the same problem in Twisted. However, we
fixed it by disabling gc *before* fork, because the gc can occur just
after the fork. See http://twistedmatrix.com/trac/ticket/2483 for the
bug report, and
Changes by Christian Heimes:
--
nosy: +tiran
priority: - normal
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1561
__
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Armin Rigo:
--
resolution: - invalid
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1285940
_
___
Python-bugs-list mailing list
Christian Heimes added the comment:
I can reproduce the problem when I run the ssl tests with -unetwork.
I've used PYTHONDUMREFS and combinerefs.py to find the leaking objects.
I'm seeing lots of
0x9fd3e4c [1] SSLSocket
0x9fd2928 [1] ssl.SSLContext ssl.SSLContext object at 0x9fd2928
0x9fd5b74
New submission from poelzi:
The Decimal class doesn't use lookups through self to construct results
in functions like __add__ to generate the resulting object. This makes
subclassing Decimal more or less senseless since all methods have to be
wrapped instead of overriding the __new__ and
Christian Heimes added the comment:
I may have found the error. The PySSL_Type doesn't support GC but it
should in order to clean up self-Socket.
I've started to fix it but I don't have time to work on the problem 'til
tonight. The patch causes a seg fault. I may have overlooked or
Christian Heimes added the comment:
I found the problem! I've to use PyObject_GC_New instead of PyObject_New
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1469
__
___
Guido van Rossum added the comment:
I get a segfault when I run it like this:
$ ./python.exe Lib/test/regrtest.py -uall test_ssl
test_ssl
Segmentation fault
$
(Without -uall it passes.)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1469
Changes by Christian Heimes:
Removed file: http://bugs.python.org/file8884/ssl_gc.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1469
__
___
Python-bugs-list mailing list
Christian Heimes added the comment:
New patch
The new patch doesn't cause a seg fault but it doesn't help. It
*increases* the number of reference leaks.
test_ssl leaked [1610, 1610] references, sum=3220
Added file: http://bugs.python.org/file8885/ssl_gc.patch
Changes by Christian Heimes:
Removed file: http://bugs.python.org/file8885/ssl_gc.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1469
__
___
Python-bugs-list mailing list
Christian Heimes added the comment:
The new patch works and fixes the ref leak. I had to move the call
self._real_close() from __del__ to PySSL_dealloc(). I don't know if you
are going to like it. :]
Added file: http://bugs.python.org/file8886/ssl_gc.patch
__
Guido van Rossum added the comment:
I will look at this in an hour or so, after I bring Orlijn to school
and drive to work.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1469
__
Roger Demetrescu added the comment:
I am not sure if it is related, but anyway...
MIMEText behaviour has changed from python 2.4 to 2.5.
# Python 2.4
from email.MIMEText import MIMEText
m = MIMEText(None, 'html', 'iso-8859-1')
m.set_payload('abc ' * 50)
print m
From nobody Thu Dec 6
Christian Heimes added the comment:
Guido van Rossum wrote:
I will look at this in an hour or so, after I bring Orlijn to school
and drive to work.
I found two problems with the _real_close() call in PySSL_dealloc. I'm
digging into it now.
o = PyObject_CallMethod((PyObject*)self-Socket,
Guido van Rossum added the comment:
Oops, I just committed revision 59394.
Please advise.
--
priority: high - immediate
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1469
__
Guido van Rossum added the comment:
I'm giving up on this for now. There are other weird bugs in the code,
e.g. this simple piece of code fails:
x = urllib.urlopen(https://mail.google.com;).read()
Traceback (most recent call last):
File stdin, line 1, in module
File
Paul Moore added the comment:
I believe that mailbox.py is expected to work with files opened in
binary mode. A long time ago I opened a bug on th email package
(http://bugs.python.org/issue586899) which turned out to be because
mailbox.py required binary mode files. The conclusion was that it
Christian Heimes added the comment:
Guido van Rossum wrote:
I just reverted it. I put a bit of debugging in the call to
_real_close(), and even with Christian's corrections it fails miserably.
I prefer leaking.
I agree! I've not enough time to work on the patch. A working patch
requires some
Changes by Christian Heimes:
--
keywords: +py3k
priority: - normal
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1563
__
___
Python-bugs-list mailing list
Changes by Guido van Rossum:
--
keywords: py3k
nosy: gvanrossum
severity: normal
status: open
title: The set implementation should special-case PyUnicode instead of PyString
versions: Python 3.0
__
Tracker [EMAIL PROTECTED]
New submission from Raymond Hettinger:
Much of the code in setobject.c exactly parallels that in dictobject.c.
Ideally, we should keep that parallelism by scanning all of the changes
to dictobject.c and applying substantially similar changes to
setobject.c (just the changes that touch the hash
Guido van Rossum added the comment:
Would it make any sense at all to refactor the code so that code reuse
is automatic?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1564
__
Amaury Forgeot d'Arc added the comment:
mailbox.py is expected to work with files opened in binary mode
Not everywhere, unfortunately. Some files are still opened in text mode.
And this makes a huge difference with py3k: one accepts bytes, the other
requires strings.
Raymond Hettinger added the comment:
Not really, the implementations are different enough that it would be
*really* hard to keep common code. The two parallel each other in a way
that is visually easy to translate but hard to do through real
refactoring. For the most part, both code bases have
Raymond Hettinger added the comment:
P.S. There is a way to factor-out some common code but it would entail
introducing a bunch of macros that hide the differences between the two.
I don't think it would be worth it.
__
Tracker [EMAIL PROTECTED]
Neil Toronto added the comment:
Attribute access that happens only once or very infrequently probably
shouldn't go through the cache machinery - it'll only slow things down.
(Updating slots for example.) Maybe _PyType_Lookup should remain the
same, with _PyType_CachingLookup added for attribute
Neil Toronto added the comment:
I've attached the microbenchmarks I was using for my own version of
attribute caching. For list, tuple, dict, and a deep hierarchy, it tests
accessing type attributes (cls.__class__), class attributes
(cls.__init__), class attributes via instance (inst.__class__),
Fantix King added the comment:
This issue also causes similar behavior on some libraries like mechanize
which depend on urljoin
--
nosy: +fantix
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1432
__
samwyse added the comment:
Refactoring sounds like a good idea. Someone would need to check how
other web servers log this, if at all. You're probably right about the
HTTP/0.9 as well.
The main reason to send a 100 response is because the client sent an
Expect: 100-continue header, and won't
30 matches
Mail list logo
