[issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self"
Claudio Freire added the comment: Nice ideas, will give them a try -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self"
Claudio Freire added the comment: The crash (the one we're experiencing) still happens with 2.7.13. But at this point it's not clear whether it's a Python bug or a Cython bug, as jdemeyer's patch doesn't fix it. We're having a hard time getting accurate backtraces to actually debug this thing, as it only happens on production servers. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self"
Claudio Freire added the comment: I cannot be 100% sure, but we have ample evidence suggesting we're experiencing this same crash in production. We have a big system that mixes Cython and pure-python coroutines, and in one version we started seeing segfaults that strongly hint at this root cause. Adding pure-python indirections (that keep the arguments alive, I'd wager), fixes those segfaults. I cannot share the codebase (and in any case it's too big, and the crash is too difficult to reproduce in isolation, without real traffic), but I'd add my +1 on applying this fix. We're currently testing to try and reproduce the segfaults on 2.7.13, after that I'll try jdemeyer's patch and report the results. -- nosy: +Claudio.Freire ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25750> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18144] FD leak in urllib2
Claudio Freire added the comment: I can confirm the issue is in urllib's open: it fails to close() the HTTP connection, leaving it to the GC to do it. If addinfourl (and friends) is altered to carry a reference to the HTTP connection and close it on close(), the leak is fixed. I have a patch but it is incomplete (just a POC), it only handles the common case I use. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18144 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18144] FD leak in urllib2
Claudio Freire added the comment: Yes, seems it does. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18144 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18493] make profile-opt fails with pre-existing python2.7 in path
New submission from Claudio Freire: When building with --enable-shared in an environment that already has a python2.7 (and I'd expect the same to happen to 3.x), make profile-opt fails because it attempts to load the existing libpython instead of the just-built one. run_profile_task should use RUNSHARED. In fact, it builds fine if $(RUNSHARED) is added to that line. Patch inline below, for 2.7.5: --- Makefile.pre.in.bk 2013-07-18 17:46:28.671773378 + +++ Makefile.pre.in 2013-07-18 17:46:47.759806100 + @@ -420,7 +420,7 @@ run_profile_task: : # FIXME: can't run for a cross build - ./$(BUILDPYTHON) $(PROFILE_TASK) + $(RUNSHARED) ./$(BUILDPYTHON) $(PROFILE_TASK) build_all_use_profile: $(MAKE) all CFLAGS=$(CFLAGS) -fprofile-use -- components: Build messages: 193313 nosy: Claudio.Freire priority: normal severity: normal status: open title: make profile-opt fails with pre-existing python2.7 in path versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18493 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18144] FD leak in urllib2
New submission from Claudio Freire:
While other issues already exist about this problem, this particular case is
unlike other issues, and I didn't think it a good idea to merge with those.
Under some very specific circumstances (sending a POST request with more data
than an unknown threshold), at least one socket remains unclosed after calling
close() on urllib2.urlopen's returned file object.
While I marked the only versions I could confirm exhibit the issue, I believe
this is an issue on all versions.
This started in pypy[0], although it applies to CPython as well (albeit the
reference counting GC is less likely to delay closing of the FD as much as in
pypy).
I'm attaching the same server used to trigger this issue in pypy, works the
same with CPython.
To trigger the leak, open an interpreter and do this (copypaste from pypy,
CPython does not cause the leak because decref immediately closes the leak, but
it will issue a wraning if ran with -Wall). See pypy's issue tracker[0] for
detilas.
import os, urllib2
req = {imp: [{h: 50, battr: [9, 10, 12], api: 3, w: 320,
instl: 0, impid: 5d6dedf3-17bb-11e2-b5c0-1040f38b83e0}] * 10
r = urllib2.Request(http://localhost:8000/bogus?src=1;, req)
u = urllib2.urlopen(r)
v = u.read()
u.close()
os.system(ls -alh /proc/%d/fd/* % os.getpid())
lrwx-- 1 claudiofreire users 64 Jun 4 15:08 /proc/26203/fd/0 - /dev/pts/5
lrwx-- 1 claudiofreire users 64 Jun 4 15:08 /proc/26203/fd/1 - /dev/pts/5
lrwx-- 1 claudiofreire users 64 Jun 4 15:08 /proc/26203/fd/2 - /dev/pts/5
lrwx-- 1 claudiofreire users 64 Jun 4 15:08 /proc/26203/fd/3 -
socket:[2086998]
lrwx-- 1 claudiofreire users 64 Jun 4 15:08 /proc/26203/fd/5 - /dev/pts/5
lrwx-- 1 claudiofreire users 64 Jun 4 15:08 /proc/26203/fd/6 - /dev/pts/5
0
[0] https://bugs.pypy.org/issue867
--
components: Library (Lib)
files: bogus.py
messages: 190687
nosy: Claudio.Freire
priority: normal
severity: normal
status: open
title: FD leak in urllib2
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file30477/bogus.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18144
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
