From tracker at bugs.pypy.org Sat Jun 1 01:49:04 2013 From: tracker at bugs.pypy.org (dktc) Date: Fri, 31 May 2013 23:49:04 +0000 Subject: [pypy-issue] [issue1506] PIL: distutils.unixccompiler requires static libraries on PyPy In-Reply-To: <1370044144.28.0.972916119046.issue1506@bugs.pypy.org> Message-ID: <1370044144.28.0.972916119046.issue1506@bugs.pypy.org> New submission from dktc : I've been trying to find out why I cannot build PIL with JPEG support on PyPy while this works fine on CPython. The problem was traced to C compiler looking for static libraries on PyPy, while being able to properly use dynamic ones on CPython. Since most devel packages are only distributed with dynamic libs that's a serious problem. To reproduce the problem in PIL/setup.py, replace find_library_file function with this: def find_library_file(self, library): print print "find_library_file: %s" % library print self.compiler print self.compiler.library_dirs print self.compiler.include_dirs result = self.compiler.find_library_file(self.compiler.library_dirs, library) print 'RESULT = %s' % result print return self.compiler.find_library_file(self.compiler.library_dirs, library) Here is the output on PyPy 2.0.2 - find_library_file: z ['/usr/local/lib', '/usr/lib'] ['libImaging', '/opt/pypy-2.0.2/include', '/usr/local/include', '/usr/include', '/opt/pypy-2.0.2/include'] RESULT = /usr/lib/libz.a find_library_file: jpeg ['/usr/local/lib', '/usr/lib'] ['libImaging', '/opt/pypy-2.0.2/include', '/usr/local/include', '/usr/include', '/opt/pypy-2.0.2/include'] RESULT = None Here is the output on CPython 2.7.3 - find_library_file: z ['/usr/local/lib', '/opt/pinax0.9a2/lib', '/usr/lib', '/opt/python2.7.3/lib'] ['libImaging', '/opt/pinax0.9a2/include', '/usr/local/include', '/usr/include', '/opt/python2.7.3/include/python2.7'] RESULT = /usr/lib/libz.so find_library_file: jpeg ['/usr/local/lib', '/opt/pinax0.9a2/lib', '/usr/lib', '/opt/python2.7.3/lib'] ['libImaging', '/opt/pinax0.9a2/include', '/usr/local/include', '/usr/include', '/opt/python2.7.3/include/python2.7'] RESULT = /usr/lib/libjpeg.so Creating fake /usr/lib/libjpeg.a with touch command fools the build, but the tests later fail, because looks like actual static linking is expected. Is there a way to fix this? ---------- messages: 5802 nosy: pypy-issue priority: bug status: unread title: PIL: distutils.unixccompiler requires static libraries on PyPy ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 1 01:53:22 2013 From: tracker at bugs.pypy.org (Fijal) Date: Fri, 31 May 2013 23:53:22 +0000 Subject: [pypy-issue] [issue1505] Removing multimethods slows the nojit case In-Reply-To: <1370014541.14.0.57716620094.issue1505@bugs.pypy.org> Message-ID: <1370044402.72.0.697607637901.issue1505@bugs.pypy.org> Fijal added the comment: I think the problem is missing fast calls in terms of lack of multimethods (signature has space after self which makes it impossible to do a fast call) and builtin speedups not working. Both should be fixed. ---------- nosy: +fijal status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 1 02:15:48 2013 From: tracker at bugs.pypy.org (dktc) Date: Sat, 01 Jun 2013 00:15:48 +0000 Subject: [pypy-issue] [issue1506] PIL: distutils.unixccompiler requires static libraries on PyPy In-Reply-To: <1370044144.28.0.972916119046.issue1506@bugs.pypy.org> Message-ID: <1370045748.13.0.766120643687.issue1506@bugs.pypy.org> dktc added the comment: One little follow-up. I found a repo with a static libjpeg ( http://rpm.pbone.net/index.php3/stat/4/idpl/15157141/dir/redhat_el_5/com/libjpeg-static-6b- 37.cubbi3.0.1.x86_64.rpm.html ), but when using it the build still fails with this output: /usr/bin/ld: skipping incompatible /usr/lib/libjpeg.so when searching for -ljpeg /usr/bin/ld: /usr/lib/libjpeg.a(jcapimin.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/libjpeg.a: could not read symbols: Bad value collect2: ld returned 1 exit status error: command 'cc' failed with exit status 1 ---------- status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 1 04:09:13 2013 From: tracker at bugs.pypy.org (Aljosa Mohorovic) Date: Sat, 01 Jun 2013 02:09:13 +0000 Subject: [pypy-issue] [issue1507] running django and celery under pypy 2.0.2 doesn't work In-Reply-To: <1370052553.02.0.191222583775.issue1507@bugs.pypy.org> Message-ID: <1370052553.02.0.191222583775.issue1507@bugs.pypy.org> New submission from Aljosa Mohorovic : running django and celery under pypy 2.0.2 results in "RuntimeError: not holding the import lock" as soon as i include "from celery import Celery" in views.py. running the same code under cpython or pypy 1.9 works as expected (checked w/ same code different virtualenvs). tested on ubuntu 13.04 $ uname -a > Linux fakanana 3.8.0-22-generic #33-Ubuntu SMP Thu May 16 15:17:14 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux on irc reproduced by pjenvey, goes away with django-admin.py runserver --nothreading or --noreload ---------- messages: 5805 nosy: aljosa, pypy-issue priority: bug release: 2.0 status: unread title: running django and celery under pypy 2.0.2 doesn't work ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 1 06:29:27 2013 From: tracker at bugs.pypy.org (dktc) Date: Sat, 01 Jun 2013 04:29:27 +0000 Subject: [pypy-issue] [issue1504] More PyPy eventlet issues In-Reply-To: <1369983076.21.0.0696376437796.issue1504@bugs.pypy.org> Message-ID: <1370060967.54.0.687823280305.issue1504@bugs.pypy.org> dktc added the comment: OK, I finally tried 2.0.2 and now it works... Strange, but I'd just leave it alone for now. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 1 06:30:37 2013 From: tracker at bugs.pypy.org (dktc) Date: Sat, 01 Jun 2013 04:30:37 +0000 Subject: [pypy-issue] [issue1503] portability of PyPy binaries In-Reply-To: <1369946424.37.0.308088885419.issue1503@bugs.pypy.org> Message-ID: <1370061037.28.0.508897616554.issue1503@bugs.pypy.org> dktc added the comment: I had an issue with how the binaries were copied and was trying old incompatible version of lxml. Please close/disregard this "error". ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 1 06:34:05 2013 From: tracker at bugs.pypy.org (dktc) Date: Sat, 01 Jun 2013 04:34:05 +0000 Subject: [pypy-issue] [issue1506] PIL: distutils.unixccompiler requires static libraries on PyPy In-Reply-To: <1370044144.28.0.972916119046.issue1506@bugs.pypy.org> Message-ID: <1370061245.02.0.74959090038.issue1506@bugs.pypy.org> dktc added the comment: Final follow-up. I was able to compile Pillow ( PIL's fork: https://github.com/python-imaging/Pillow ) with these static libraries from ATrpms.net (libjpeg and libfreetype). While I have my solution for now, I believe it is still important to find out why PyPy is not using dynamically linked libraries, whether this is a bug or a feature and how this could be changed/fixed. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 1 10:55:09 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 01 Jun 2013 08:55:09 +0000 Subject: [pypy-issue] [issue1506] PIL: distutils.unixccompiler requires static libraries on PyPy In-Reply-To: <1370044144.28.0.972916119046.issue1506@bugs.pypy.org> Message-ID: <1370076909.4.0.0279732292753.issue1506@bugs.pypy.org> Armin Rigo added the comment: What command are you using to get this? Just "pip install pillow" or similar? ---------- nosy: +arigo ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 1 11:11:03 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 01 Jun 2013 09:11:03 +0000 Subject: [pypy-issue] [issue1506] PIL: distutils.unixccompiler requires static libraries on PyPy In-Reply-To: <1370044144.28.0.972916119046.issue1506@bugs.pypy.org> Message-ID: <1370077863.77.0.160782059871.issue1506@bugs.pypy.org> Armin Rigo added the comment: Ok, fuond the problem. Distutils is missing "libjpeg.so" because it's looking for "libjpeg.pypy-20.so". ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 1 11:51:37 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 01 Jun 2013 09:51:37 +0000 Subject: [pypy-issue] [issue1506] PIL: distutils.unixccompiler requires static libraries on PyPy In-Reply-To: <1370044144.28.0.972916119046.issue1506@bugs.pypy.org> Message-ID: <1370080297.19.0.370160199757.issue1506@bugs.pypy.org> Armin Rigo added the comment: I may have fixed it in 722471a15693. ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 1 18:28:51 2013 From: tracker at bugs.pypy.org (Aljosa Mohorovic) Date: Sat, 01 Jun 2013 16:28:51 +0000 Subject: [pypy-issue] [issue1507] running django and celery under pypy 2.0.2 doesn't work In-Reply-To: <1370052553.02.0.191222583775.issue1507@bugs.pypy.org> Message-ID: <1370104131.79.0.443962834483.issue1507@bugs.pypy.org> Aljosa Mohorovic added the comment: example code and steps to reproduce available at https://github.com/aljosa/pypy- django-celery ---------- status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 2 04:40:35 2013 From: tracker at bugs.pypy.org (dktc) Date: Sun, 02 Jun 2013 02:40:35 +0000 Subject: [pypy-issue] [issue1506] PIL: distutils.unixccompiler requires static libraries on PyPy In-Reply-To: <1370044144.28.0.972916119046.issue1506@bugs.pypy.org> Message-ID: <1370140835.27.0.860541132756.issue1506@bugs.pypy.org> dktc added the comment: Does distutils always look for things like "libjpeg.pypy-20.so"? I could not build with freetype either. Is your fix removing the need for any modification of library names? ---------- status: resolved -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 2 10:34:27 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 02 Jun 2013 08:34:27 +0000 Subject: [pypy-issue] [issue1506] PIL: distutils.unixccompiler requires static libraries on PyPy In-Reply-To: <1370044144.28.0.972916119046.issue1506@bugs.pypy.org> Message-ID: <1370162067.46.0.494231113145.issue1506@bugs.pypy.org> Armin Rigo added the comment: Yes, and yes. You can try to apply the diff of 722471a15693: it only changes two files in lib-python/2.7/distutils/, which means you can just do the same changes to an otherwise regular pypy 2.0.2 binary package and see if it helps. ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 2 10:39:01 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 02 Jun 2013 08:39:01 +0000 Subject: [pypy-issue] [issue1507] running django and celery under pypy 2.0.2 doesn't work In-Reply-To: <1370052553.02.0.191222583775.issue1507@bugs.pypy.org> Message-ID: <1370162341.19.0.977894980406.issue1507@bugs.pypy.org> Armin Rigo added the comment: Thanks, that's great :-) ---------- nosy: +arigo ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 2 11:14:37 2013 From: tracker at bugs.pypy.org (kostia.lopuhin) Date: Sun, 02 Jun 2013 09:14:37 +0000 Subject: [pypy-issue] [issue1508] PyPy 2.0 does not respect default encoding In-Reply-To: <1370164477.92.0.374739151145.issue1508@bugs.pypy.org> Message-ID: <1370164477.92.0.374739151145.issue1508@bugs.pypy.org> New submission from kostia.lopuhin : When default encoding is set to utf-8 via import sys sys.setdefaultencoding('utf-8') CPython respects it /usr/bin/python Python 2.7.2 (default, Oct 11 2012, 20:14:37) [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin >>> import sys >>> sys.getdefaultencoding() 'utf-8' >>> 'fasd ????? %s' % u'?????' u'fasd \u0430\u0444\u044b\u0432\u0430 \u0430\u0444\u044b\u0432\u0430' And PyPy (both OS X and Ubuntu) does not: python Python 2.7.3 (b9c3566aa017, May 09 2013, 15:27:31) [PyPy 2.0.0 with GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.27)] on darwin >>>> import sys >>>> sys.getdefaultencoding() 'utf-8' >>>> 'fasd ????? %s' % u'?????' Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 5: ordinal not in range(128) ---------- messages: 5816 nosy: kostia.lopuhin, pypy-issue priority: bug release: 2.0 status: unread title: PyPy 2.0 does not respect default encoding ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 2 13:32:30 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 02 Jun 2013 11:32:30 +0000 Subject: [pypy-issue] [issue1507] running django and celery under pypy 2.0.2 doesn't work In-Reply-To: <1370052553.02.0.191222583775.issue1507@bugs.pypy.org> Message-ID: <1370172750.02.0.799497373555.issue1507@bugs.pypy.org> Armin Rigo added the comment: Resolved the original problem in 51f304544a4b. The next issue was found and resolved in 3cdac1ac25eb. Now a page saying just "home" shows, which I take to mean it's ok. ---------- status: testing -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 2 16:04:01 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 02 Jun 2013 14:04:01 +0000 Subject: [pypy-issue] [issue1508] PyPy 2.0 does not respect default encoding In-Reply-To: <1370164477.92.0.374739151145.issue1508@bugs.pypy.org> Message-ID: <1370181841.78.0.589453518509.issue1508@bugs.pypy.org> Armin Rigo added the comment: Can you give more details? This issue is messy because it depends on your terminal, on your environment variables, and so on. We can't tell on which encoding what you type interactively is sent to the interpreter. What would help is a file "x.py" that you attach to this bug report, such that "python x.py" works and "pypy x.py" doesn't, as well as the output of "env" to see which environment variables you have. Also, I guess that in order to use "setdefaultencoding()" you'd actually need "python -S" and "pypy -S" (i.e. don't run site.py; the name sys.setdefaultencoding is normally killed by site.py). ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 2 16:29:00 2013 From: tracker at bugs.pypy.org (kostia.lopuhin) Date: Sun, 02 Jun 2013 14:29:00 +0000 Subject: [pypy-issue] [issue1508] PyPy 2.0 does not respect default encoding In-Reply-To: <1370164477.92.0.374739151145.issue1508@bugs.pypy.org> Message-ID: <1370183340.92.0.242557712978.issue1508@bugs.pypy.org> kostia.lopuhin added the comment: Attached x.py and (maybe in the next comment) test session, where x.py fails under pypy 2.0 and passed under cpython 2.7. This also fails when run under gunicorn that is managed by supervisord. I am happy to give more info, thank you for looking into this! ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 2 20:48:14 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 02 Jun 2013 18:48:14 +0000 Subject: [pypy-issue] [issue1508] PyPy 2.0 does not respect default encoding In-Reply-To: <1370164477.92.0.374739151145.issue1508@bugs.pypy.org> Message-ID: <1370198894.43.0.956772344504.issue1508@bugs.pypy.org> Armin Rigo added the comment: Fixed in 64c70e584a54, thanks! ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Jun 3 09:14:35 2013 From: tracker at bugs.pypy.org (kostia.lopuhin) Date: Mon, 03 Jun 2013 07:14:35 +0000 Subject: [pypy-issue] [issue1508] PyPy 2.0 does not respect default encoding In-Reply-To: <1370164477.92.0.374739151145.issue1508@bugs.pypy.org> Message-ID: <1370243675.57.0.327008297909.issue1508@bugs.pypy.org> kostia.lopuhin added the comment: Thank you! This fix should apply cleanly to 2.0x as well? ---------- status: resolved -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Jun 3 17:16:59 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Mon, 03 Jun 2013 15:16:59 +0000 Subject: [pypy-issue] [issue1508] PyPy 2.0 does not respect default encoding In-Reply-To: <1370164477.92.0.374739151145.issue1508@bugs.pypy.org> Message-ID: <1370272619.11.0.040669649136.issue1508@bugs.pypy.org> Armin Rigo added the comment: Yes. Thanks for the hint, I applied it to the branch 'release-2.0.x' too, just in case we decide to do 2.0.3 at some time. ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 4 13:53:59 2013 From: tracker at bugs.pypy.org (dktc) Date: Tue, 04 Jun 2013 11:53:59 +0000 Subject: [pypy-issue] [issue1509] weird crashes with eventlet/spawning In-Reply-To: <1370346839.72.0.630041821939.issue1509@bugs.pypy.org> Message-ID: <1370346839.72.0.630041821939.issue1509@bugs.pypy.org> New submission from dktc : I've discovered some really strange behavior with PyPy 2.0.2. Not familiar enough with PyPy / eventlet architecture to trace this bug further, but can report the conditions causing it: 1) Install Spawning master ( https://github.com/rtyler/Spawning/ ) with eventlet 0.12.1 2) Create a sample Django 1.5 app and set it up as WSGI under Spawning 3) Start Spawning with 3 processes, 4 threads and --sysinfo option 4) Open http://domain.com/_sysinfo to see that --sysinfo interceptor works fine 5) Open any regular page from Django app, reload it several times 6) Try to open http://domain.com/_sysinfo again and note that it times out / crashes 7) Try steps 4-6 a few more times if the crash does not occur immediately 8) Note that if you do a process listing "ps aux" there will be more child processes than expected 9) Note that killing parent/controller process after crash won't terminate the children This behavior does not happen on CPython 2.7.4 - all pages load correctly, the number of children always stays as specified and terminating the controller causes termination of all children. There have to be some bugs in PyPy to be causing this behavior... ---------- messages: 5823 nosy: pypy-issue priority: bug release: 2.0 status: unread title: weird crashes with eventlet/spawning ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 4 14:04:44 2013 From: tracker at bugs.pypy.org (mikefc) Date: Tue, 04 Jun 2013 12:04:44 +0000 Subject: [pypy-issue] [issue1510] numpypy argsort segmentation fault In-Reply-To: <1370347484.82.0.635718303061.issue1510@bugs.pypy.org> Message-ID: <1370347484.82.0.635718303061.issue1510@bugs.pypy.org> New submission from mikefc : ndarray.argsort() has a malloc error/segmentation fault for arrays of some sizes #------------------------- # Code: argsort.py #------------------------- from random import random import numpypy as np rows = 510 # 400, 600 work fine. Values around 500 segfault cols = 2 a = np.array([random() for _ in xrange(rows*cols)]) a = a.reshape((rows, cols)) a.argsort() #------------------------- # Result using latest nightly on OSX #------------------------- >> pypy argsort.py # using rows = 510 pypy(35947) malloc: *** error for object 0x102a2b7e0: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Abort trap: 6 >> pypy argsort.py # using rows = 520 Segmentation fault: 11 ---------- messages: 5824 nosy: mikefc, pypy-issue priority: bug status: unread title: numpypy argsort segmentation fault ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 4 18:50:29 2013 From: tracker at bugs.pypy.org (Claudio) Date: Tue, 04 Jun 2013 16:50:29 +0000 Subject: [pypy-issue] [issue867] urllib2 on pypy can leak fd's In-Reply-To: <1315669439.97.0.201746613632.issue867@bugs.pypy.org> Message-ID: <1370364629.88.0.697140648687.issue867@bugs.pypy.org> Claudio added the comment: I'm experiencing this in 2.0.2. A simple test, having a web server in localhost answering this request: req = """balblabla""" url = "http://localhost:8000/blah?whatever=1" r = urllib2.Request(url, req) u = urllib2.urlopen(r) v = u.read() u.close() os.system("ls -alh /proc/%d/fd/*" % os.getpid()) I get: >>>> os.system("ls -alh /proc/%d/fd/*" % os.getpid()) lrwx------ 1 claudiofreire users 64 Jun 4 13:42 /proc/23471/fd/0 -> /dev/pts/1 lrwx------ 1 claudiofreire users 64 Jun 4 13:42 /proc/23471/fd/1 -> /dev/pts/1 lrwx------ 1 claudiofreire users 64 Jun 4 13:42 /proc/23471/fd/2 -> /dev/pts/1 lrwx------ 1 claudiofreire users 64 Jun 4 13:42 /proc/23471/fd/3 -> socket:[1072689] lrwx------ 1 claudiofreire users 64 Jun 4 13:42 /proc/23471/fd/5 -> /dev/pts/1 lrwx------ 1 claudiofreire users 64 Jun 4 13:42 /proc/23471/fd/6 -> /dev/pts/1 0 However, if I don't use a payload, I have no leak: >>>> import urllib2 >>>> u = urllib2.urlopen("http://www.google.com.ar") >>>> v = u.read() >>>> u.close() >>>> import os >>>> os.system("ls -alh /proc/%d/fd/*" % os.getpid()) lrwx------ 1 claudiofreire users 64 Jun 4 13:49 /proc/23570/fd/0 -> /dev/pts/1 lrwx------ 1 claudiofreire users 64 Jun 4 13:49 /proc/23570/fd/1 -> /dev/pts/1 lrwx------ 1 claudiofreire users 64 Jun 4 13:49 /proc/23570/fd/2 -> /dev/pts/1 lrwx------ 1 claudiofreire users 64 Jun 4 13:49 /proc/23570/fd/5 -> /dev/pts/1 lrwx------ 1 claudiofreire users 64 Jun 4 13:49 /proc/23570/fd/6 -> /dev/pts/1 0 CPython 2.7.3 does not exhibit this issue ---------- nosy: +klauss status: resolved -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 4 19:52:46 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d Arc) Date: Tue, 04 Jun 2013 17:52:46 +0000 Subject: [pypy-issue] [issue867] urllib2 on pypy can leak fd's In-Reply-To: <1315669439.97.0.201746613632.issue867@bugs.pypy.org> Message-ID: <1370368366.27.0.355847874958.issue867@bugs.pypy.org> Amaury Forgeot d Arc added the comment: I cannot reproduce this. But maybe it depends on the server? do you have a full running example? ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 4 20:10:19 2013 From: tracker at bugs.pypy.org (Claudio) Date: Tue, 04 Jun 2013 18:10:19 +0000 Subject: [pypy-issue] [issue867] urllib2 on pypy can leak fd's In-Reply-To: <1315669439.97.0.201746613632.issue867@bugs.pypy.org> Message-ID: <1370369419.51.0.939544455138.issue867@bugs.pypy.org> Claudio added the comment: Indeed, it seems somewhat specific to my case, simpler applications don't trigger the bug. But I managed to reduce it to this: >>>> 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 >>>> Run the attached tornado application (not sure it's specific to tornado, but I did manage to reproduce it with tornado) Notice that tornado can be running in CPython or pypy in my test, both work fine. It's in urllib2 the leak. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 4 20:43:18 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d Arc) Date: Tue, 04 Jun 2013 18:43:18 +0000 Subject: [pypy-issue] [issue867] urllib2 on pypy can leak fd's In-Reply-To: <1315669439.97.0.201746613632.issue867@bugs.pypy.org> Message-ID: <1370371398.82.0.400104247494.issue867@bugs.pypy.org> Amaury Forgeot d Arc added the comment: This issue should be reported to CPython as well: in python3 sockets are supposed to be careful to not rely on reference counting, yet when I run your script with "python3 -Wall" I see the warning: /usr/lib/python3.2/socket.py:339: ResourceWarning: unclosed self._sock = None And as expected, with PyPy a gc.collect() closes the socket. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 5 01:10:14 2013 From: tracker at bugs.pypy.org (mikefc) Date: Tue, 04 Jun 2013 23:10:14 +0000 Subject: [pypy-issue] [issue1510] numpypy argsort segmentation fault In-Reply-To: <1370347484.82.0.635718303061.issue1510@bugs.pypy.org> Message-ID: <1370387414.82.0.381052313693.issue1510@bugs.pypy.org> mikefc added the comment: Update: There are lots of values for which this crashes with a malloc error rows = 1 .. 16 => malloc error rows = 17 .. 74 => works etc I've had a look at the argsort() implementation looking for a stray malloc/free, but it's beyond my understanding. ---------- status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 5 01:13:04 2013 From: tracker at bugs.pypy.org (Fijal) Date: Tue, 04 Jun 2013 23:13:04 +0000 Subject: [pypy-issue] [issue1510] numpypy argsort segmentation fault In-Reply-To: <1370347484.82.0.635718303061.issue1510@bugs.pypy.org> Message-ID: <1370387584.04.0.619519641312.issue1510@bugs.pypy.org> Fijal added the comment: It's most likely an out-of-bound array access and not a malloc/free problem. ---------- nosy: +fijal ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 5 16:53:45 2013 From: tracker at bugs.pypy.org (Iason) Date: Wed, 05 Jun 2013 14:53:45 +0000 Subject: [pypy-issue] [issue1511] boto 2.9.5 slow In-Reply-To: <1370444025.93.0.530439968591.issue1511@bugs.pypy.org> Message-ID: <1370444025.93.0.530439968591.issue1511@bugs.pypy.org> New submission from Iason : testing pypy 2.0.2 and python 2.7.4 using boto 2.9.5 the script initiates a connection to AWS Simple Queue Service (Ireland) and returns a Simple Queue then 10 messages are extracted form the queue packages used from boto.sqs import connect_to_region as sqs_connect from boto.sqs.message import RawMessage as SQSMessage i5 2.4 Ghz 6gb ram time required for a batch of 10 messages ~ 2 secs in python time required for a batch of 10 messages ~ 17 secs in pypy amazon m1.medium instance 2 compute cores/ 8 gb ram time required for a batch of 10 messages ~ 2 secs in python time required for a batch of 10 messages ~ 8 secs in pypy ---------- messages: 5831 nosy: impakogi, pypy-issue priority: performance bug status: unread title: boto 2.9.5 slow ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 5 21:12:48 2013 From: tracker at bugs.pypy.org (Claudio) Date: Wed, 05 Jun 2013 19:12:48 +0000 Subject: [pypy-issue] [issue867] urllib2 on pypy can leak fd's In-Reply-To: <1315669439.97.0.201746613632.issue867@bugs.pypy.org> Message-ID: <1370459568.96.0.106913810716.issue867@bugs.pypy.org> Claudio added the comment: Done[0] [0] http://bugs.python.org/issue18144 ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 6 07:58:40 2013 From: tracker at bugs.pypy.org (dktc) Date: Thu, 06 Jun 2013 05:58:40 +0000 Subject: [pypy-issue] [issue1512] import lock problem crashes PyPy In-Reply-To: <1370498320.27.0.727914666822.issue1512@bugs.pypy.org> Message-ID: <1370498320.27.0.727914666822.issue1512@bugs.pypy.org> New submission from dktc : I have a multi-processing, multi-threaded Django app that crashes when a secondary thread is trying to import a package that was not previously imported in the main thread. The environment is the same as in https://bugs.pypy.org/issue1509 with PyPy 2.0.2. I suspect the root causes of the error might also be somehow connected. Strangely enough this error is quite fickle and only reproduces irregularly. The stacktrace simply shows that the error occurs on the "import" statement - ... my custom error message ... Traceback (most recent call last): ... my stack trace ... import mypackage RuntimeError: not holding the import lock Here is the error message that is urging me to report a bug - Fatal error in cpyext, CPython compatibility layer, calling PyEval_SaveThread Either report a bug or consider not using this particular extension RPython traceback: RPython traceback: File "pypy_interpreter_generator.c", line 2267, in portal_11 File "pypy_module_cpyext_api.c", line 35140, in PyEval_SaveThread File "rpython_jit_metainterp_warmstate.c", line 14489, in maybe_compile_and_run__star_4_1 File "rpython_jit_metainterp_warmstate.c", line 21788, in execute_assembler__star_3_7 File "rpython_jit_metainterp_blackhole.c", line 874, in _run_forever File "rpython_jit_metainterp_blackhole.c", line 3301, in _handle_jitexception Fatal RPython error: AssertionError File "rpython_jit_metainterp_compile.c", line 23635, in ResumeGuardDescr_handle_fail Fatal RPython error: AssertionError (7455) Child died from signal 6 with code 0 ---------- messages: 5833 nosy: pypy-issue priority: bug release: 2.0 status: unread title: import lock problem crashes PyPy ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 6 20:16:21 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 06 Jun 2013 18:16:21 +0000 Subject: [pypy-issue] [issue1509] weird crashes with eventlet/spawning In-Reply-To: <1370346839.72.0.630041821939.issue1509@bugs.pypy.org> Message-ID: <1370542581.15.0.242214959637.issue1509@bugs.pypy.org> Armin Rigo added the comment: dktc: thanks for the many bug reports you did :-) I can't do anything with this one, but others that know Django might. (For me a report like this one is useless unless it contains something more precise than "Create a sample Django app", which I don't know how to do and which will might not have the same problem anyway. I need instead instructions like: pip install django, download this attached sample.py, run "pypy sample.py --exact-options" or whatever the command-line is, and so on.) ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 6 20:21:58 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 06 Jun 2013 18:21:58 +0000 Subject: [pypy-issue] [issue1511] boto 2.9.5 slow In-Reply-To: <1370444025.93.0.530439968591.issue1511@bugs.pypy.org> Message-ID: <1370542918.88.0.482875692859.issue1511@bugs.pypy.org> Armin Rigo added the comment: Is that a C extension module-based package? If it is, it's used "cpyext" which is known to be slow. Otherwise, if it is pure Python, then it's indeed interesting, but we'd need some instructions to reproduce the slow-down ourselves. ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 6 20:26:00 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 06 Jun 2013 18:26:00 +0000 Subject: [pypy-issue] [issue1501] Minor English bugs in rpython documentation In-Reply-To: <1369769834.64.0.443474862555.issue1501@bugs.pypy.org> Message-ID: <1370543160.62.0.545778738205.issue1501@bugs.pypy.org> Armin Rigo added the comment: Thanks :-) Fixed in da8f1e729f4d. ---------- nosy: +arigo status: unread -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 6 23:06:46 2013 From: tracker at bugs.pypy.org (dktc) Date: Thu, 06 Jun 2013 21:06:46 +0000 Subject: [pypy-issue] [issue1509] weird crashes with eventlet/spawning In-Reply-To: <1370346839.72.0.630041821939.issue1509@bugs.pypy.org> Message-ID: <1370552806.1.0.372318736369.issue1509@bugs.pypy.org> dktc added the comment: No worries, I understand this sort of bug is not easy to reproduce, but that's exactly why IMHO this should be looked into as some pretty rigorous testing. I'd like to be able to run PyPy in production under heavy load in multi-processing / multi- threaded environment and looks like it might uncover a few issues like this. I'd definitely suggest setting up Django and doing more testing under it as a common real-world scenario. Here is the tutorial on what you need to do after "pip install django". I suggest you try the tutorial app: https://docs.djangoproject.com/en/1.5/intro/ Note, that most of the likely issues here are not in Django itself, but in Spawning/Eventlet which act as Django's WSGI container and heavily rely on Python's multi-processing / multi-threading facilities - where the likely problems are. Most of the tracing to do is within Spawning code, specifically spawning_child.py and spawning_controller.py Spawning is based on Eventlet and can be set up according to the Github instructions. I recommend getting the latest from Github as it contains a Django 1.5 compatibility fix: "pip install -e git+http://github.com/rtyler/spawning.git#egg=spawning" Hope this helps with getting started on this issue. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 7 11:36:49 2013 From: tracker at bugs.pypy.org (mikefc) Date: Fri, 07 Jun 2013 09:36:49 +0000 Subject: [pypy-issue] [issue1510] numpypy argsort segmentation fault In-Reply-To: <1370347484.82.0.635718303061.issue1510@bugs.pypy.org> Message-ID: <1370597809.89.0.427740657428.issue1510@bugs.pypy.org> mikefc added the comment: The segaults only seem to happen on float32/float64. The int32/64 types don't have an issue. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 7 13:06:10 2013 From: tracker at bugs.pypy.org (mikefc) Date: Fri, 07 Jun 2013 11:06:10 +0000 Subject: [pypy-issue] [issue1510] numpypy argsort segmentation fault In-Reply-To: <1370347484.82.0.635718303061.issue1510@bugs.pypy.org> Message-ID: <1370603170.33.0.515292196093.issue1510@bugs.pypy.org> mikefc added the comment: fijal, In pypy/pypy/module/micronumpy/arrayimpl/sort.py::Repr.setitem(), should the last line of that function: raw_storage_setitem(self.indexes, idx * self.index_stride_size + self.index_start, item[1]) be changed to: raw_storage_setitem(self.indexes, idx * self.index_stride_size + self.index_start, INT_SIZE) As it is, it seems that raw_storage_setitem is trying to set the size the index rawstorage to item[1], which I think is the size of the *values* being sorted not the size of the indices. I'm probably still way off base, but that's all I've got so far. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 7 16:28:24 2013 From: tracker at bugs.pypy.org (mattip) Date: Fri, 07 Jun 2013 14:28:24 +0000 Subject: [pypy-issue] [issue1510] numpypy argsort segmentation fault In-Reply-To: <1370347484.82.0.635718303061.issue1510@bugs.pypy.org> Message-ID: <1370615304.26.0.719414156858.issue1510@bugs.pypy.org> mattip added the comment: I added a failing test in the argsort-segfault branch, run it with python pytest.py pypy/module/micronumpy/test/test_numarray.py -k argsort_random -s dumps core for me on linux64 in arg_getitem_slice Still searching for the cause, I added lots of print statements ---------- nosy: +mattip ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 8 06:59:39 2013 From: tracker at bugs.pypy.org (Fijal) Date: Sat, 08 Jun 2013 04:59:39 +0000 Subject: [pypy-issue] [issue1511] boto 2.9.5 slow In-Reply-To: <1370444025.93.0.530439968591.issue1511@bugs.pypy.org> Message-ID: <1370667579.96.0.905455573751.issue1511@bugs.pypy.org> Fijal added the comment: This looks like pure python - please provide instructions how to reproduce it though. First of all there is no program to run, second I have no idea what the things you mentioned mean. ---------- nosy: +fijal ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Jun 10 01:17:55 2013 From: tracker at bugs.pypy.org (Julian Berman) Date: Sun, 09 Jun 2013 23:17:55 +0000 Subject: [pypy-issue] [issue1513] Curses crash: TypeError: initializer for ctype 'char *' must be a str or list or tuple, not unicode In-Reply-To: <1370819875.07.0.573577522811.issue1513@bugs.pypy.org> Message-ID: <1370819875.07.0.573577522811.issue1513@bugs.pypy.org> New submission from Julian Berman : Python 2.7.3 (5acfe049a5b0, May 21 2013, 13:47:22) [PyPy 2.0.2 with GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] Getting the following traceback with a curses app (bpython): ? bpython -i wsgi.py Julian at air Traceback (most recent call last): File "app_main.py", line 72, in run_toplevel File "/Users/Julian/.local/share/virtualenvs/great/bin/bpython", line 9, in load_entry_point('bpython==0.12', 'console_scripts', 'bpython')() File "/Users/Julian/.local/share/virtualenvs/great/site- packages/bpython/cli.py", line 1918, in main banner=banner) File "/Users/Julian/.local/share/virtualenvs/great/site- packages/bpython/cli.py", line 1815, in curses_wrapper return func(stdscr, *args, **kwargs) File "/Users/Julian/.local/share/virtualenvs/great/site- packages/bpython/cli.py", line 1888, in main_curses exit_value = clirepl.repl() File "/Users/Julian/.local/share/virtualenvs/great/site- packages/bpython/cli.py", line 1116, in repl inp = self.get_line() File "/Users/Julian/.local/share/virtualenvs/great/site- packages/bpython/cli.py", line 673, in get_line if self.p_key(key) is None: File "/Users/Julian/.local/share/virtualenvs/great/site- packages/bpython/cli.py", line 1011, in p_key self.addstr(key) File "/Users/Julian/.local/share/virtualenvs/great/site- packages/bpython/cli.py", line 348, in addstr self.complete() File "/Users/Julian/.local/share/virtualenvs/great/site- packages/bpython/cli.py", line 448, in complete self.show_list(self.matches, self.argspec) File "/Users/Julian/.local/share/virtualenvs/great/site- packages/bpython/cli.py", line 1271, in show_list height_offset = self.mkargspec(topline, down) + 1 File "/Users/Julian/.local/share/virtualenvs/great/site- packages/bpython/cli.py", line 722, in mkargspec get_colpair(self.config, 'name') | curses.A_BOLD) File "/usr/local/Cellar/pypy/2.0.2/lib_pypy/_curses.py", line 509, in _wrapped return func(self, *outargs) File "/usr/local/Cellar/pypy/2.0.2/lib_pypy/_curses.py", line 598, in addstr code = lib.waddstr(self._win, text) TypeError: initializer for ctype 'char *' must be a str or list or tuple, not unicode Don't have time to investigate further at this exact moment, so apologies, but the quickest way to reproduce is: $ mktmpenv --python=pypy $ pip install bpython flask $ bpython >>> import flask >>> flask.Flask and then hit (, which will trigger bpython's tooltip for docstrings and along with it that traceback. If I get some time to dig I'll update with more details, though I bet this means enough to let you guys know what's up already if you're familiar with the curses integration code. ---------- messages: 5842 nosy: Julian, pypy-issue priority: bug release: 2.0 status: unread title: Curses crash: TypeError: initializer for ctype 'char *' must be a str or list or tuple, not unicode ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 11 09:14:12 2013 From: tracker at bugs.pypy.org (YAMAMOTO Takashi) Date: Tue, 11 Jun 2013 07:14:12 +0000 Subject: [pypy-issue] [issue1514] module behaviour incompatibility which makes eventlet fail In-Reply-To: <1370934852.01.0.927470601666.issue1514@bugs.pypy.org> Message-ID: <1370934852.01.0.927470601666.issue1514@bugs.pypy.org> New submission from YAMAMOTO Takashi : the following code behaves differently on cpython and pypy. it breaks eventlet monkey pathcing. --------------- import select import sys f = select.select setattr(select, 'select', None) assert f != select.select # save, re-import, restore. # this is essentially what eventlet.patcher does. modname = 'select' saved = sys.modules.get(modname) sys.modules.pop(modname) __import__(modname) sys.modules[modname] = saved assert f != select.select # this succeeds on cpython but fails on pypy. ---------- messages: 5843 nosy: pypy-issue, yamt priority: bug status: unread title: module behaviour incompatibility which makes eventlet fail ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 11 11:27:53 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Tue, 11 Jun 2013 09:27:53 +0000 Subject: [pypy-issue] [issue1514] module behaviour incompatibility which makes eventlet fail In-Reply-To: <1370934852.01.0.927470601666.issue1514@bugs.pypy.org> Message-ID: <1370942873.78.0.846962961388.issue1514@bugs.pypy.org> Armin Rigo added the comment: Uh. I won't ask why eventlet does it (as on CPython it seems to have no effect). Instead we can fix it so that re-importing built-in modules has no effect either on PyPy. ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 11 12:32:29 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d Arc) Date: Tue, 11 Jun 2013 10:32:29 +0000 Subject: [pypy-issue] [issue1514] module behaviour incompatibility which makes eventlet fail In-Reply-To: <1370934852.01.0.927470601666.issue1514@bugs.pypy.org> Message-ID: <1370946749.27.0.331463336602.issue1514@bugs.pypy.org> Amaury Forgeot d Arc added the comment: Noteworthy fact: "import select" will reload the module, AND store it in the current namespace __import__('select') will reload the module BUT leave the old module in the namespace. CPython and PyPy both initialize a builtin module only once, and make a shallow copy of its initial __dict__. On the next import, this initial dict is used to refresh the module, no init function is called. The difference is that CPython will create a new module instance each time, when PyPy has only one prebuilt instance (stored in space.builtin_modules). This won't be a simple change. As a workaround, instead of saving the module, you could save a copy of its __dict__ instead: saved = sys.modules.get(modname).__dict__.copy() ...pop, import... sys.modules[modname].__dict__.update(saved) ---------- nosy: +amaury ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 11 13:06:15 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Tue, 11 Jun 2013 11:06:15 +0000 Subject: [pypy-issue] [issue1514] module behaviour incompatibility which makes eventlet fail In-Reply-To: <1370934852.01.0.927470601666.issue1514@bugs.pypy.org> Message-ID: <1370948775.39.0.302781788878.issue1514@bugs.pypy.org> Armin Rigo added the comment: I thought I fixed it in f26956c61773; at least, enough to have the reported test case work. But indeed, I didn't fix the difference reported by Amaury: repeating an import on a built-in or extension module which has been removed from sys.modules will, on CPython, create a new module object. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 11 13:40:08 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Tue, 11 Jun 2013 11:40:08 +0000 Subject: [pypy-issue] [issue1514] module behaviour incompatibility which makes eventlet fail In-Reply-To: <1370934852.01.0.927470601666.issue1514@bugs.pypy.org> Message-ID: <1370950808.0.0.162119071283.issue1514@bugs.pypy.org> Armin Rigo added the comment: Indeed, the fix I did is wrong: it's possible to write a simpler test that now fails (but this simpler test as not written so far, bad us). Reverted my changes to the code for now. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 12 05:05:23 2013 From: tracker at bugs.pypy.org (andrewsmedina) Date: Wed, 12 Jun 2013 03:05:23 +0000 Subject: [pypy-issue] [issue1511] boto 2.9.5 slow In-Reply-To: <1370444025.93.0.530439968591.issue1511@bugs.pypy.org> Message-ID: <1371006323.44.0.391805832847.issue1511@bugs.pypy.org> andrewsmedina added the comment: SQS is as queue/message system as a service provided by aws (amazon webservices). And boto is a python client for aws. The boto code is here: https://github.com/boto/boto I dont know what the code used by impakogi does. But I think that get 10 messages of a queue is to small to be considered. I can try create a bench test for send and get messages from sqs queue. What do you think? ---------- nosy: +andrewsmedina ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 12 06:05:41 2013 From: tracker at bugs.pypy.org (andrewsmedina) Date: Wed, 12 Jun 2013 04:05:41 +0000 Subject: [pypy-issue] [issue1479] Uses all my memory and slow In-Reply-To: <1367982780.12.0.260641386288.issue1479@bugs.pypy.org> Message-ID: <1371009941.97.0.959320513997.issue1479@bugs.pypy.org> andrewsmedina added the comment: I tried to install sentry on pypy without success. A error happened when I was installing the setproctitle: https://gist.github.com/andrewsmedina/5762750 I'm using: $ pypy Python 2.7.3 (d8b79f042e37, Jun 04 2013, 22:00:32) [PyPy 2.1.0-alpha0 with GCC 4.2.1 Compatible Clang Compiler] on darwin ---------- nosy: +andrewsmedina ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 12 06:23:26 2013 From: tracker at bugs.pypy.org (andrewsmedina) Date: Wed, 12 Jun 2013 04:23:26 +0000 Subject: [pypy-issue] [issue1479] Uses all my memory and slow In-Reply-To: <1367982780.12.0.260641386288.issue1479@bugs.pypy.org> Message-ID: <1371011006.59.0.25241048462.issue1479@bugs.pypy.org> andrewsmedina added the comment: python-dev works with pypy? using cpython2.7 the 'pip install setproctitle' works fine. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 12 09:09:43 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d Arc) Date: Wed, 12 Jun 2013 07:09:43 +0000 Subject: [pypy-issue] [issue1479] Uses all my memory and slow In-Reply-To: <1367982780.12.0.260641386288.issue1479@bugs.pypy.org> Message-ID: <1371020983.69.0.0722482995144.issue1479@bugs.pypy.org> Amaury Forgeot d Arc added the comment: "error: Python.h: No such file or directory" Is pypy correctly installed? which version of virtualenv did you use? Are there files (or links) in the /Users/andrews/.virtualenvs/sentrypypy/include directory? ---------- nosy: +amaury ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 12 10:20:06 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Wed, 12 Jun 2013 08:20:06 +0000 Subject: [pypy-issue] [issue1513] Curses crash: TypeError: initializer for ctype 'char *' must be a str or list or tuple, not unicode In-Reply-To: <1370819875.07.0.573577522811.issue1513@bugs.pypy.org> Message-ID: <1371025206.68.0.822411888222.issue1513@bugs.pypy.org> Armin Rigo added the comment: Should be fixed in 0c8571de8df4. Thanks! ---------- nosy: +arigo status: unread -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 12 11:31:37 2013 From: tracker at bugs.pypy.org (Iason) Date: Wed, 12 Jun 2013 09:31:37 +0000 Subject: [pypy-issue] [issue1511] boto 2.9.5 slow In-Reply-To: <1370444025.93.0.530439968591.issue1511@bugs.pypy.org> Message-ID: <1371029497.95.0.413922206662.issue1511@bugs.pypy.org> Iason added the comment: Sorry guys, boto is what andrewsmedina has described. I have pinpointed the problem to the time it takes to retrieve messages from the queue. I will supply a test script shortly, but you will need amazon subscription to test this. 10 messages are a big thing because it is the maximum batch one can retrieve from amazon sqs I performed tests retrieving 1,2,3 ... etc and in all occasions pypy is very slow ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Jun 12 14:28:39 2013 From: tracker at bugs.pypy.org (andrewsmedina) Date: Wed, 12 Jun 2013 12:28:39 +0000 Subject: [pypy-issue] [issue1479] Uses all my memory and slow In-Reply-To: <1367982780.12.0.260641386288.issue1479@bugs.pypy.org> Message-ID: <1371040119.91.0.466291692138.issue1479@bugs.pypy.org> andrewsmedina added the comment: I was using the virtualenvwrapper==3.6 I update it to the last version and the install worked fine. Thanks ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 14 07:10:20 2013 From: tracker at bugs.pypy.org (mikefc) Date: Fri, 14 Jun 2013 05:10:20 +0000 Subject: [pypy-issue] [issue1510] numpypy argsort segmentation fault In-Reply-To: <1370347484.82.0.635718303061.issue1510@bugs.pypy.org> Message-ID: <1371186620.22.0.13110716418.issue1510@bugs.pypy.org> mikefc added the comment: mattip, thanks for setting that up. I've had a couple of goes over the last week at tracking down the bug on this branch, but haven't got any closer. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 14 08:27:48 2013 From: tracker at bugs.pypy.org (mikefc) Date: Fri, 14 Jun 2013 06:27:48 +0000 Subject: [pypy-issue] [issue1510] numpypy argsort segmentation fault In-Reply-To: <1370347484.82.0.635718303061.issue1510@bugs.pypy.org> Message-ID: <1371191268.15.0.966235828317.issue1510@bugs.pypy.org> mikefc added the comment: I can make the test pass by changing /pypy/module/micronumpy/arrayimpl/sort.py Just allocate twice as much memory for the indexes i.e. - indexes = dtype.itemtype.malloc(size*dtype.get_size()) + indexes = dtype.itemtype.malloc(2 * size * dtype.get_size()) This is not a fix, obviously. But at least it narrows the hunt... ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 14 08:46:24 2013 From: tracker at bugs.pypy.org (mikefc) Date: Fri, 14 Jun 2013 06:46:24 +0000 Subject: [pypy-issue] [issue1510] numpypy argsort segmentation fault In-Reply-To: <1370347484.82.0.635718303061.issue1510@bugs.pypy.org> Message-ID: <1371192384.89.0.903014923704.issue1510@bugs.pypy.org> mikefc added the comment: Sorry for update flood: I think the problem is that there are 2 definitions for the size of the numeric value used for the index array. During the malloc, dtype = interp_dtype.get_dtype_cache(space).w_longdtype indexes = dtype.itemtype.malloc(size * dtype.get_size()) This dtype has a get_size() of 8. However, index_stride_size is set to 16, and raw_storage_setitem() and raw_storage_getitem() use this value for accessing the raw_storage i.e. raw_storage_setitem(self.indexes, idx * self.index_stride_size + self.index_start, item[1]) Does this look right at all? ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 14 15:10:43 2013 From: tracker at bugs.pypy.org (mattip) Date: Fri, 14 Jun 2013 13:10:43 +0000 Subject: [pypy-issue] [issue1510] numpypy argsort segmentation fault In-Reply-To: <1370347484.82.0.635718303061.issue1510@bugs.pypy.org> Message-ID: <1371215443.55.0.915885282159.issue1510@bugs.pypy.org> mattip added the comment: I prefer this change, the index array was allocated properly but we used an improper stride on it - Repr.__init__(self, index_stride_size, stride_size, - size, values, indexes, start, start) + Repr.__init__(self, dtype.get_size(), stride_size, + size, values, indexes, start, start) We only hit this code when doing piece wise sorting on multidimensional arrays, which we did not test until now. I pushed this into changeset 938d68eb8a73, thanks mikefc! ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 14 17:04:15 2013 From: tracker at bugs.pypy.org (mattip) Date: Fri, 14 Jun 2013 15:04:15 +0000 Subject: [pypy-issue] [issue1510] numpypy argsort segmentation fault In-Reply-To: <1370347484.82.0.635718303061.issue1510@bugs.pypy.org> Message-ID: <1371222255.79.0.223384231876.issue1510@bugs.pypy.org> mattip added the comment: fix merged into default ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 16 10:10:34 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 16 Jun 2013 08:10:34 +0000 Subject: [pypy-issue] [issue1515] buildbot failure: tk In-Reply-To: <1371370234.0.0.866803698299.issue1515@bugs.pypy.org> Message-ID: <1371370234.0.0.866803698299.issue1515@bugs.pypy.org> New submission from Armin Rigo : Please [1] fix tk so that it raises ImportError if tcl.h/tk.h are not found; and [2] afterwards, install it on some common buildbots, to make sure it is tested. (I can do [2] but would like [1] to be done first.) ---------- messages: 5861 nosy: arigo, pypy-issue priority: bug status: unread title: buildbot failure: tk ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 16 17:48:45 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 16 Jun 2013 15:48:45 +0000 Subject: [pypy-issue] [issue1516] Pure Python Interpreter slow In-Reply-To: <1371397725.98.0.402100605559.issue1516@bugs.pypy.org> Message-ID: <1371397725.98.0.402100605559.issue1516@bugs.pypy.org> New submission from Armin Rigo : Reported by vegard1992 on irc: this is a pure Python interpreter that runs a lot slower on PyPy than on CPython. ---------- files: forpypy.tar.bz2 messages: 5862 nosy: arigo, pypy-issue priority: performance bug status: unread title: Pure Python Interpreter slow ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 16 18:30:36 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d Arc) Date: Sun, 16 Jun 2013 16:30:36 +0000 Subject: [pypy-issue] [issue1515] buildbot failure: tk In-Reply-To: <1371370234.0.0.866803698299.issue1515@bugs.pypy.org> Message-ID: <1371400236.64.0.734868164151.issue1515@bugs.pypy.org> Amaury Forgeot d Arc added the comment: [1] done with b5cea7cd6c02. ---------- nosy: +amaury status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 16 19:23:11 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 16 Jun 2013 17:23:11 +0000 Subject: [pypy-issue] [issue1516] Pure Python Interpreter slow In-Reply-To: <1371397725.98.0.402100605559.issue1516@bugs.pypy.org> Message-ID: <1371403391.54.0.508036803414.issue1516@bugs.pypy.org> Armin Rigo added the comment: It might be a misunderstanding of "the JIT needs warm-up": it runs for around 0.05 seconds. By adding a loop, repeating 100 or 1000 times "machine.load_cartridge() and .run()" in testing.py, the result is respectively 1.5x faster and 3x faster on PyPy than on CPython. ---------- status: unread -> invalid ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 16 19:49:42 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 16 Jun 2013 17:49:42 +0000 Subject: [pypy-issue] [issue1515] buildbot failure: tk In-Reply-To: <1371370234.0.0.866803698299.issue1515@bugs.pypy.org> Message-ID: <1371404982.48.0.139585214217.issue1515@bugs.pypy.org> Armin Rigo added the comment: Installed "tk-dev" on tannit32. Why does test___all__ still fails? Because it doesn't expect the debugging output from the C compiler? ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 16 20:55:22 2013 From: tracker at bugs.pypy.org (Yaroslav Fedevych) Date: Sun, 16 Jun 2013 18:55:22 +0000 Subject: [pypy-issue] =?utf-8?q?=5Bissue1486=5D_Pypy_disk_IO_is_slower_tha?= =?utf-8?b?biBweXRob24yLjbvvJ8=?= In-Reply-To: <1368620039.71.0.0263891291277.issue1486@bugs.pypy.org> Message-ID: <1371408922.93.0.243501353399.issue1486@bugs.pypy.org> Yaroslav Fedevych added the comment: Can't help but notice two things: 0) close is missing parentheses ? which in my case leads to too many open files on PyPy (due to GC differences, of course), but could be, say, swapping the cause of slowdown? The file objects just sit there waiting to be collected... 1) can't be the difference due to the JIT warmup? A test case that gives more work (like recursively reading all user-accessible files starting at /) would be a bit more convincing... 2) I tried to run the attached test case on recent PyPy build and noticed that profile is giving funny results: bigbuddy:~ jafd$ time pypy -mprofile test.py 17221 function calls in 1086664311533356.250 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 867 -45897692753392.812 -52938515286.497 -45897692753392.812 -52938515286.497 :0(__new__) 867 -30272791276041.523 -34916714274.558 -30272791276041.523 -34916714274.558 :0(__setattr__) 836 2115208175656.440 2530153320.163 2115208175656.440 2530153320.163 :0(close) 1703 -39838690480920.453 -23393241621.210 -39838690480920.453 -23393241621.210 :0(endswith) 1734 -54779616801475.984 -31591474510.655 -54779616801475.984 -31591474510.655 :0(len) 1 -549755.812 -549755.812 -549755.812 -549755.812 :0(listdir) 1 0.002 0.002 0.002 0.002 :0(setprofile) 1703 -42086944674548.781 -24713414371.432 -42086944674548.781 -24713414371.432 :0(startswith) 867 2335352521858491.500 2693601524634.938 1843735061872581.500 2126568698814.973 :0(stat) 3468 -145999709112752.812 -42099108740.701 -145999709112752.812 -42099108740.701 _structseq.py:22(__get__) 867 -260203318219848.438 -300119167496.942 -391153419050758.750 -451157346079.307 _structseq.py:70(structseq_new) 867 -171200198957734.906 -197462743895.888 1475320231703065.000 1701638098850.133 genericpath.py:26(isfile) 1703 -173595051423241.812 -101934851099.966 -255520686578711.094 -150041507092.608 posixpath.py:60(join) 1 0.001 0.001 1086664311533435.375 1086664311533435.375 profile:0(, file 'test.py', line 1>) 0 0.000 0.000 profile:0(profiler) 867 -33930050370621.383 -39135006194.488 -33930050370621.383 -39135006194.488 stat.py:24(S_IFMT) 867 -117748912663560.141 -135811894652.318 -151678963034181.531 -174946900846.807 stat.py:49(S_ISREG) 1 0.001 0.001 1086664311533435.375 1086664311533435.375 test.py:1() 1 -135250441216896.922 -135250441216896.922 1086664311533435.375 1086664311533435.375 test.py:3(main) real 0m5.250s user 0m4.717s sys 0m0.470s profile here is terribly wrong, as shown by time command output and the fact that I was able to see the script start and finish in my lifetime. Not sure if this profile.py timing should be split to a bug of its own. ---------- nosy: +jafd ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 16 21:47:30 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 16 Jun 2013 19:47:30 +0000 Subject: [pypy-issue] =?utf-8?q?=5Bissue1486=5D_Pypy_disk_IO_is_slower_tha?= =?utf-8?b?biBweXRob24yLjbvvJ8=?= In-Reply-To: <1368620039.71.0.0263891291277.issue1486@bugs.pypy.org> Message-ID: <1371412050.89.0.548308415187.issue1486@bugs.pypy.org> Armin Rigo added the comment: jafd: please open a bug more specifically for the profile times errors. I couldn't reproduce it on linux (32/64)... ---------- nosy: +arigo ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 16 22:36:57 2013 From: tracker at bugs.pypy.org (flaper87) Date: Sun, 16 Jun 2013 20:36:57 +0000 Subject: [pypy-issue] [issue1517] lib-python/logging behaves differently from standard python logging module In-Reply-To: <1371415017.8.0.45207104506.issue1517@bugs.pypy.org> Message-ID: <1371415017.8.0.45207104506.issue1517@bugs.pypy.org> New submission from flaper87 : Pypy's logging module, in some cases, behaves differently from the standard python logging module. For example, https://bitbucket.org/pypy/pypy/src/b4b26fd9fe5be1855a8e4caebe0d2e3c5f3f1015/lib-python/2.7/logging/__init__.py?at=default#cl-157 in standard python returns the level constant either an int is passed or a string. the big difference is here http://hg.python.org/releasing/2.7.4/file/9290822f2280/Lib/logging/__init__.py#l137 https://bitbucket.org/pypy/pypy/src/b4b26fd9fe5be1855a8e4caebe0d2e3c5f3f1015/lib-python/2.7/logging/__init__.py?at=default#cl-137 phantom (pypy*) workspace/openstack/marconi $ python2.7 Python 2.7.4 (default, Apr 6 2013, 19:20:36) [GCC 4.8.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import logging >>> logging.getLevelName('WARN') 30 >>> (.venvpy)phantom (pypy*) workspace/openstack/marconi $ python Python 2.7.3 (23314bb14a1f, Jun 16 2013, 08:12:59) [PyPy 2.1.0-alpha0 with GCC 4.8.0 20130502 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``The time decreases!'' >>>> import logging >>>> logging.getLevelName('WARN') 'Level WARN' >>>> What is the right procedure / rule to update files under lib-python ? ---------- assignedto: flaper87 messages: 5868 nosy: flaper87, pypy-issue priority: bug status: chatting title: lib-python/logging behaves differently from standard python logging module ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Jun 17 00:10:56 2013 From: tracker at bugs.pypy.org (flaper87) Date: Sun, 16 Jun 2013 22:10:56 +0000 Subject: [pypy-issue] [issue1517] lib-python/logging behaves differently from standard python logging module In-Reply-To: <1371415017.8.0.45207104506.issue1517@bugs.pypy.org> Message-ID: <1371420656.73.0.939778948515.issue1517@bugs.pypy.org> flaper87 added the comment: Proposed fix https://bitbucket.org/pypy/pypy/pull-request/156/return-levels-constant-when- levels-name-is/diff ---------- status: chatting -> in-progress ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Jun 17 04:39:02 2013 From: tracker at bugs.pypy.org (Fijal) Date: Mon, 17 Jun 2013 02:39:02 +0000 Subject: [pypy-issue] [issue1517] lib-python/logging behaves differently from standard python logging module In-Reply-To: <1371415017.8.0.45207104506.issue1517@bugs.pypy.org> Message-ID: <1371436742.3.0.478779386742.issue1517@bugs.pypy.org> Fijal added the comment: It seems like an incompatible change in CPython between 2.7.3 and 2.7.4. I have no idea why. ---------- nosy: +fijal ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Jun 17 04:40:01 2013 From: tracker at bugs.pypy.org (Alex Gaynor) Date: Mon, 17 Jun 2013 02:40:01 +0000 Subject: [pypy-issue] [issue1517] lib-python/logging behaves differently from standard python logging module In-Reply-To: <1371415017.8.0.45207104506.issue1517@bugs.pypy.org> Message-ID: <1371436801.74.0.058686513332.issue1517@bugs.pypy.org> Alex Gaynor added the comment: I made the change in the PyPy repo (it was a backport of a change in 3.4). The fix flaper87 did is merged. ---------- nosy: +agaynor status: in-progress -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 18 13:36:21 2013 From: tracker at bugs.pypy.org (Carl Friedrich Bolz) Date: Tue, 18 Jun 2013 11:36:21 +0000 Subject: [pypy-issue] [issue1518] setting PYTHONINSPECT during a script run won't start interactive mode in pypy In-Reply-To: <1371555381.62.0.376742745434.issue1518@bugs.pypy.org> Message-ID: <1371555381.62.0.376742745434.issue1518@bugs.pypy.org> New submission from Carl Friedrich Bolz : The script below will start interactive mode in CPython, but not in pypy. (I tried to debug it, but as usual I got confused what exactly putenv is supposed to do). import os os.putenv("PYTHONINSPECT", "1") ---------- messages: 5872 nosy: cfbolz, pypy-issue priority: bug status: unread title: setting PYTHONINSPECT during a script run won't start interactive mode in pypy ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Jun 18 14:17:00 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d Arc) Date: Tue, 18 Jun 2013 12:17:00 +0000 Subject: [pypy-issue] [issue1518] setting PYTHONINSPECT during a script run won't start interactive mode in pypy In-Reply-To: <1371555381.62.0.376742745434.issue1518@bugs.pypy.org> Message-ID: <1371557820.66.0.597966689742.issue1518@bugs.pypy.org> Amaury Forgeot d Arc added the comment: os.putenv() calls the libc function. To start interactive mode, CPython calls the libc function getenv(), and retrieve the value. OTOH in pypy we use the applevel os.getenv() which reads os.environ, which was built from a snapshot of the environment at interpreter startup. The solution could be to access the *RPython-level* os.environ[]: this one calls the libc getenv() on each item access (thanks to the magic in ll_os_environ.py) Maybe expose this as posix._getenv(), and use it in app_main.py. tag:easy ---------- nosy: +amaury status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Jun 20 14:24:02 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d Arc) Date: Thu, 20 Jun 2013 12:24:02 +0000 Subject: [pypy-issue] [issue1519] ABORT_BAD_LOOP with innocent looking loops In-Reply-To: <1371731042.76.0.483953886348.issue1519@bugs.pypy.org> Message-ID: <1371731042.76.0.483953886348.issue1519@bugs.pypy.org> New submission from Amaury Forgeot d Arc : The attached script (simplified from a real lxml benchmark) will emit an ABORT_BAD_LOOP several times. Does this mean that this function cannot be jitted? what's the reason? ---------- files: testjit.py messages: 5874 nosy: amaury, pypy-issue priority: performance bug status: unread title: ABORT_BAD_LOOP with innocent looking loops ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 21 12:46:24 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 21 Jun 2013 10:46:24 +0000 Subject: [pypy-issue] [issue1257] Memory leak when using web.py In-Reply-To: <1347220762.49.0.575714347026.issue1257@bugs.pypy.org> Message-ID: <1371811584.48.0.632849710447.issue1257@bugs.pypy.org> Armin Rigo added the comment: Cannot reproduce, at least on PyPy 2.0.2. After a run time of 2 minutes the PyPy process is still only at 70MB of resident size. Tested by running "pip install web.py cherrypy" and "pypy test_httpservice2.py" and "while /bin/true; do wget --quiet --no-check-certificate https://127.0.0.1:8700 && rm index.html*; done". ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 22 15:31:01 2013 From: tracker at bugs.pypy.org (Kenny Levinsen) Date: Sat, 22 Jun 2013 13:31:01 +0000 Subject: [pypy-issue] [issue1520] Fatal RPython error: OSError when working dir is removed In-Reply-To: <1371907861.14.0.935325807488.issue1520@bugs.pypy.org> Message-ID: <1371907861.14.0.935325807488.issue1520@bugs.pypy.org> New submission from Kenny Levinsen : Issue: If the current directory is removed, attempts to execute a script in it will cause an OSError: RPython traceback: File "pypy_goal_targetpypystandalone.c", line 2558, in entry_point File "pypy_interpreter_pyframe.c", line 1344, in PyFrame_execute_frame File "rpython_jit_metainterp_warmspot.c", line 1496, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit_interp_jit.c", line 258, in portal_4 File "pypy_interpreter_pyopcode.c", line 3422, in handle_bytecode__AccessDirect_None File "pypy_interpreter_pyopcode.c", line 9401, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_pyopcode.c", line 17875, in call_function__AccessDirect_None File "pypy_interpreter_pyframe.c", line 1344, in PyFrame_execute_frame File "rpython_jit_metainterp_warmspot.c", line 1496, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit_interp_jit.c", line 258, in portal_4 File "pypy_interpreter_pyopcode.c", line 3422, in handle_bytecode__AccessDirect_None File "pypy_interpreter_pyopcode.c", line 12722, in dispatch_bytecode__AccessDirect_None File "pypy_objspace_std_callmethod.c", line 4110, in CALL_METHOD__AccessDirect_star_1 File "pypy_interpreter_gateway.c", line 411, in BuiltinCode1_fastcall_1 File "pypy_interpreter_gateway.c", line 2747, in BuiltinCode_handle_exception Fatal RPython error: OSError An example scenario of this happening would be changing branches in version control back and forth between branches containing a directory. Going back to an old shell that was in that directory, and trying to execute a script in the directory will fail, as it was removed and recreated under your feet. Reproduction: mkdir dir cd dir rmdir ../dir pypy test.py Watch pypy crash and burn ---------- messages: 5876 nosy: joushou, pypy-issue priority: bug release: 2.0 status: unread title: Fatal RPython error: OSError when working dir is removed ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 22 17:55:50 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 22 Jun 2013 15:55:50 +0000 Subject: [pypy-issue] [issue1520] Fatal RPython error: OSError when working dir is removed In-Reply-To: <1371907861.14.0.935325807488.issue1520@bugs.pypy.org> Message-ID: <1371916550.42.0.297699064891.issue1520@bugs.pypy.org> Armin Rigo added the comment: Fixed in 30e24bcbd0e5. Maybe we should have a system that detects automatically which RPython exceptions can reach entry_point(), and work to fix all such places... ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 28 06:06:35 2013 From: tracker at bugs.pypy.org (YAMAMOTO Takashi) Date: Fri, 28 Jun 2013 04:06:35 +0000 Subject: [pypy-issue] [issue1514] module behaviour incompatibility which makes eventlet fail In-Reply-To: <1370934852.01.0.927470601666.issue1514@bugs.pypy.org> Message-ID: <1372392395.01.0.283232583564.issue1514@bugs.pypy.org> YAMAMOTO Takashi added the comment: amaury's workaround to update __dict__ would work for this simple testcase. but unfortunately it doesn't make much sense for eventlet because it wants to use both of patched and unpatched versions of the module. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 28 06:14:31 2013 From: tracker at bugs.pypy.org (YAMAMOTO Takashi) Date: Fri, 28 Jun 2013 04:14:31 +0000 Subject: [pypy-issue] [issue1514] module behaviour incompatibility which makes eventlet fail In-Reply-To: <1370934852.01.0.927470601666.issue1514@bugs.pypy.org> Message-ID: <1372392871.76.0.693377179134.issue1514@bugs.pypy.org> YAMAMOTO Takashi added the comment: probably this is a better test case. ----------------- import sys import select original = select.select m = __import__('select') setattr(m, 'select', None) assert select.select == None assert m.select == None # reload del sys.modules['select'] import select assert select.select == original assert m.select == None # this fails on pypy ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 28 09:19:52 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d Arc) Date: Fri, 28 Jun 2013 07:19:52 +0000 Subject: [pypy-issue] [issue1514] module behaviour incompatibility which makes eventlet fail In-Reply-To: <1370934852.01.0.927470601666.issue1514@bugs.pypy.org> Message-ID: <1372403992.56.0.167255621665.issue1514@bugs.pypy.org> Amaury Forgeot d Arc added the comment: "use both of patched and unpatched versions of the module." Did you try to copy the module then? m = type(sys)('select') m.__dict__.update(select.__dict__) Of course pypy should do it in __import__. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 28 17:52:28 2013 From: tracker at bugs.pypy.org (Sergey Shepelev) Date: Fri, 28 Jun 2013 15:52:28 +0000 Subject: [pypy-issue] [issue1521] greenlet compatibility: .switch does not accept **kwargs In-Reply-To: <1372434748.84.0.246670526081.issue1521@bugs.pypy.org> Message-ID: <1372434748.84.0.246670526081.issue1521@bugs.pypy.org> New submission from Sergey Shepelev : As greenlet docs say, their switch accepts both *args and **kwargs. https://greenlet.readthedocs.org/en/latest/greenlet.html?highlight=switch#switching g.switch(*args, **kwargs) Eventlet relies on that and passes some kwargs. Currently, a lot of Eventlet tests fail like this: ====================================================================== FAIL: test_025_accept_errors (tests.wsgi_test.TestHttpd) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/temoto/dev/github.com/eventlet/eventlet/tests/wsgi_test.py", line 762, in test_025_accept_errors self.logfile.getvalue()) AssertionError: Traceback (most recent call last): File "/home/temoto/dev/github.com/eventlet/eventlet/eventlet/hubs/hub.py", line 346, in fire_timers timer() File "/home/temoto/dev/github.com/eventlet/eventlet/eventlet/hubs/timer.py", line 56, in __call__ cb(*args, **kw) TypeError: switch() got 4 unexpected keyword arguments It is so awesome that you guys added stackless support in 2.0; how do you think would it be possible to fix this compatibility also? If someone would briefly describe state of affairs with your unbound_method() here https://bitbucket.org/pypy/pypy/src/default/lib_pypy/greenlet.py#cl-81 I could try to it myself. Thank you. ---------- nosy: +temoto status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 28 18:47:06 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 28 Jun 2013 16:47:06 +0000 Subject: [pypy-issue] [issue1521] greenlet compatibility: .switch does not accept **kwargs In-Reply-To: <1372434748.84.0.246670526081.issue1521@bugs.pypy.org> Message-ID: <1372438026.43.0.66171698834.issue1521@bugs.pypy.org> Armin Rigo added the comment: This was not the case in "my" version of greenlet, and it must have been added later. The arguments to switch() are sent either to the starting function if the greenlet was not started yet, or as the return value of another switch() if it was started already. I guess it only makes sense to pass **kwargs when we're in the first case? Indeed, how would a function call return some keyword arguments? (It's already a bit of a hack because if there are more than one *args then a tuple is returned.) ---------- nosy: +arigo ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 28 19:15:23 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 28 Jun 2013 17:15:23 +0000 Subject: [pypy-issue] [issue1521] greenlet compatibility: .switch does not accept **kwargs In-Reply-To: <1372434748.84.0.246670526081.issue1521@bugs.pypy.org> Message-ID: <1372439723.85.0.684991328975.issue1521@bugs.pypy.org> Armin Rigo added the comment: No, they extended the hack to more cases. 'greenlet.switch()' can return a 2-tuple (args-tuple, kwds)... Needs to investigate. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Jun 28 19:46:59 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 28 Jun 2013 17:46:59 +0000 Subject: [pypy-issue] [issue1521] greenlet compatibility: .switch does not accept **kwargs In-Reply-To: <1372434748.84.0.246670526081.issue1521@bugs.pypy.org> Message-ID: <1372441619.47.0.330071437836.issue1521@bugs.pypy.org> Armin Rigo added the comment: Fixed in 307d5501ecf6, I think. (I did it because it's a quick hack for me, sorry for robbing you of a chance to get into pypy :-) but it's a mess, handling args and now kwds...) ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 29 12:18:23 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d Arc) Date: Sat, 29 Jun 2013 10:18:23 +0000 Subject: [pypy-issue] [issue1392] _checkClosed method is misisng in io.RawIOBase In-Reply-To: <1360404665.6.0.144734969058.issue1392@bugs.pypy.org> Message-ID: <1372501103.22.0.0570370414303.issue1392@bugs.pypy.org> Amaury Forgeot d Arc added the comment: I finally applied the change as e83efe56cd20. Thanks for the patch! ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Jun 29 15:04:00 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 29 Jun 2013 13:04:00 +0000 Subject: [pypy-issue] [issue1470] Implement python3 sys.setswitchinterval() In-Reply-To: <1367164198.61.0.86586358164.issue1470@bugs.pypy.org> Message-ID: <1372511040.38.0.420382036142.issue1470@bugs.pypy.org> Armin Rigo added the comment: Note that PyPy's method is almost like CPython, but with an additional twist: the thread that releases the GIL is not allowed to be the first one to acquire it again, if another thread is waiting. We should think about this in the context of the JIT. Right now every compiled loop decrements the "bytecode counter" by some amount computed a bit randomly from the length of the loop. We could instead use the fast instruction to get the CPU timer. Note that there are additional CPU-dependent issues, like the fact that the CPU timers of multiple cores are out-of-sync; moreover it's unclear if other CPUs than x86 have a required super-efficient timer. These are all reasons for why the current solution works "well enough", and why it's a bit delicate to change it without a global RPython change (that would also affect other interpreters than PyPy-for-3.2). ---------- nosy: +arigo -pjenvey status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Jun 30 19:28:49 2013 From: tracker at bugs.pypy.org (Jorge) Date: Sun, 30 Jun 2013 17:28:49 +0000 Subject: [pypy-issue] [issue1522] In some cases, `set(itertools.ifilter(...` takes more memory than in CPython In-Reply-To: <1372613329.04.0.947040665165.issue1522@bugs.pypy.org> Message-ID: <1372613329.04.0.947040665165.issue1522@bugs.pypy.org> New submission from Jorge : The attached file uses half a GiB of RAM to run in PyPy (2.0.2 and 1.9.0), but very little in CPython (~5 MiB), and it's also 2x slower. Notice that the sequence argument in ifilter is important: the commented out line uses little memory, though it's still slower. ---------- files: test_case.py messages: 5887 nosy: jorge, pypy-issue priority: performance bug status: unread title: In some cases, `set(itertools.ifilter(...` takes more memory than in CPython ________________________________________ PyPy bug tracker ________________________________________