From tracker at bugs.pypy.org Sun Sep 1 10:55:29 2013 From: tracker at bugs.pypy.org (Florian Schulze) Date: Sun, 01 Sep 2013 08:55:29 +0000 Subject: [pypy-issue] [issue1593] segfault with ctypes callback on OS X In-Reply-To: <1378025729.36.0.512335519021.issue1593@bugs.pypy.org> Message-ID: <1378025729.36.0.512335519021.issue1593@bugs.pypy.org> New submission from Florian Schulze : When I run the code below I consistently get a segfault a few seconds after touching the trackpad with several fingers. Even if I do nothing inside the callback except "return 0" I get the segfault. It seems like MTDeviceStart spawns a new thread in which the callback is called. It works fine with Python 2.7.5. import time import ctypes import threading CFArrayRef = ctypes.c_void_p CFMutableArrayRef = ctypes.c_void_p CFIndex = ctypes.c_long MultitouchSupport = ctypes.CDLL("/System/Library/PrivateFrameworks/MultitouchSupport.framework/MultitouchSupport") CFArrayGetCount = MultitouchSupport.CFArrayGetCount CFArrayGetCount.argtypes = [CFArrayRef] CFArrayGetCount.restype = CFIndex CFArrayGetValueAtIndex = MultitouchSupport.CFArrayGetValueAtIndex CFArrayGetValueAtIndex.argtypes = [CFArrayRef, CFIndex] CFArrayGetValueAtIndex.restype = ctypes.c_void_p MTDeviceCreateList = MultitouchSupport.MTDeviceCreateList MTDeviceCreateList.argtypes = [] MTDeviceCreateList.restype = CFMutableArrayRef class MTPoint(ctypes.Structure): _fields_ = [("x", ctypes.c_float), ("y", ctypes.c_float)] class MTVector(ctypes.Structure): _fields_ = [("position", MTPoint), ("velocity", MTPoint)] class MTData(ctypes.Structure): _fields_ = [ ("frame", ctypes.c_int), ("timestamp", ctypes.c_double), ("identifier", ctypes.c_int), ("state", ctypes.c_int), # Current state (of unknown meaning). ("unknown1", ctypes.c_int), ("unknown2", ctypes.c_int), ("normalized", MTVector), # Normalized position and vector of # the touch (0 to 1). ("size", ctypes.c_float), # The area of the touch. ("unknown3", ctypes.c_int), # The following three define the ellipsoid of a finger. ("angle", ctypes.c_float), ("major_axis", ctypes.c_float), ("minor_axis", ctypes.c_float), ("unknown4", MTVector), ("unknown5_1", ctypes.c_int), ("unknown5_2", ctypes.c_int), ("unknown6", ctypes.c_float), ] MTDataRef = ctypes.POINTER(MTData) MTContactCallbackFunction = ctypes.CFUNCTYPE(ctypes.c_int, ctypes.c_int, MTDataRef, ctypes.c_int, ctypes.c_double, ctypes.c_int) MTDeviceRef = ctypes.c_void_p MTRegisterContactFrameCallback = MultitouchSupport.MTRegisterContactFrameCallback MTRegisterContactFrameCallback.argtypes = [MTDeviceRef, MTContactCallbackFunction] MTRegisterContactFrameCallback.restype = None MTDeviceStart = MultitouchSupport.MTDeviceStart MTDeviceStart.argtypes = [MTDeviceRef, ctypes.c_int] MTDeviceStart.restype = None ### @MTContactCallbackFunction def my_callback(device, data_ptr, n_fingers, timestamp, frame): print threading.current_thread(), device, data_ptr, n_fingers, timestamp, frame for i in xrange(n_fingers): data = data_ptr[i] d = "x=%.2f, y=%.2f" % (data.normalized.position.x * 100, data.normalized.position.y * 100) print "%d: %s" % (i, d) return 0 devices = MultitouchSupport.MTDeviceCreateList() num_devices = CFArrayGetCount(devices) print "num_devices =", num_devices for i in xrange(num_devices): device = CFArrayGetValueAtIndex(devices, i) print "device #%d: %016x" % (i, device) MTRegisterContactFrameCallback(device, my_callback) MTDeviceStart(device, 0) print threading.current_thread() while threading.active_count(): # Why sleep instead of join? Ask David Beazley. time.sleep(0.125) ---------- messages: 6107 nosy: fschulze, pypy-issue priority: bug status: unread title: segfault with ctypes callback on OS X ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 1 10:57:02 2013 From: tracker at bugs.pypy.org (Florian Schulze) Date: Sun, 01 Sep 2013 08:57:02 +0000 Subject: [pypy-issue] [issue1593] segfault with ctypes callback on OS X In-Reply-To: <1378025729.36.0.512335519021.issue1593@bugs.pypy.org> Message-ID: <1378025822.39.0.714786455635.issue1593@bugs.pypy.org> Florian Schulze added the comment: Forgot to mention that I tried it with the pypy 2.1 release. ---------- status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 1 11:41:03 2013 From: tracker at bugs.pypy.org (mattip) Date: Sun, 01 Sep 2013 09:41:03 +0000 Subject: [pypy-issue] [issue1532] Running ipython with pypy on windows In-Reply-To: <1373550270.76.0.0364406526498.issue1532@bugs.pypy.org> Message-ID: <1378028463.11.0.433920031765.issue1532@bugs.pypy.org> mattip added the comment: _curses does not exist on windows, can we solve this with the following at the top of lib_pypy\_curses.py ------------- if sys.platform == 'win32': raise ImportError('no _curses on windows') -------------- ---------- nosy: +mattip priority: wish -> bug status: chatting -> in-progress ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 1 21:00:39 2013 From: tracker at bugs.pypy.org (kostia.lopuhin) Date: Sun, 01 Sep 2013 19:00:39 +0000 Subject: [pypy-issue] [issue1594] Assertion error with pypy-stm and tornado In-Reply-To: <1378062039.39.0.547595908984.issue1594@bugs.pypy.org> Message-ID: <1378062039.39.0.547595908984.issue1594@bugs.pypy.org> New submission from kostia.lopuhin : Running tornado with (maybe broken) stm support fails with the following error: pypy: /home/kostia/pypy/rpython/translator/stm/src_stm/steal.c:338: stm_normalize_stolen_objects: Assertion `L->h_tid & GCFLAG_PRIVATE_FROM_PROTECTED' failed. Aborted (core dumped) Executable was translated on Ubuntu 12.04, using 5904f9845d8c+ (stmgc-static-barrier): pypy ../../rpython/bin/rpython --opt=2 --gc=stmgc --gcrootfinder=stm --stm targetpypystandalone.py I tested that it generally works (and stm also works and scales as expected on small examples). How to reproduce (assuming virtualenv with pypy-stm): pip install -e git+git at github.com:lopuhin/tornado.git at stm#egg=tornado git clone git at github.com:lopuhin/web_bench.git Install siege (on Ubuntu the package name is siege), and run in one window (4 is the number of threads). pypy web_bench/trnado.py 4 8001 And in another siege -c 200 -t 10s http://localhost:8001/foo/1000 and see pypy fail with assertion error. Sertanly my tornado modification https://github.com/lopuhin/tornado/commit/246c5e71ce8792b20c56049cf2e3eff192a01b20 may be broken, but if I fool transaction module to belive that pypy has no stm support like this: hg diff diff -r 5904f9845d8c lib_pypy/transaction.py --- a/lib_pypy/transaction.py Fri Aug 23 20:10:41 2013 +0200 +++ b/lib_pypy/transaction.py Sun Sep 01 22:47:27 2013 +0400 @@ -15,6 +15,7 @@ import sys, thread, collections, cStringIO, linecache try: + raise ImportError from __pypy__.thread import atomic except ImportError: # Not a STM-enabled PyPy. We can still provide a version of 'atomic' @@ -41,6 +42,7 @@ signals_enabled = _SignalsEnabled() try: + raise ImportError from __pypy__.thread import last_abort_info except ImportError: # Not a STM-enabled PyPy. then all runs fine. Also, if I run only callbacks in parallel (and don't run handlers in parallel) than the failure is the same. ---------- messages: 6110 nosy: kostia.lopuhin, pypy-issue priority: bug status: unread title: Assertion error with pypy-stm and tornado ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 2 14:01:19 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Mon, 02 Sep 2013 12:01:19 +0000 Subject: [pypy-issue] [issue1593] segfault with ctypes callback on OS X In-Reply-To: <1378025729.36.0.512335519021.issue1593@bugs.pypy.org> Message-ID: <1378123279.73.0.792899068341.issue1593@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: Can you check ctypes.sizeof(MTData)? Does it have the same size as with CPython? ---------- nosy: +amaury ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 2 17:29:21 2013 From: tracker at bugs.pypy.org (Florian Schulze) Date: Mon, 02 Sep 2013 15:29:21 +0000 Subject: [pypy-issue] [issue1593] segfault with ctypes callback on OS X In-Reply-To: <1378025729.36.0.512335519021.issue1593@bugs.pypy.org> Message-ID: <1378135761.32.0.617838645618.issue1593@bugs.pypy.org> Florian Schulze added the comment: It's the same for both: MTVector 16 MTPoint 8 MTData 96 I get data back for a few single and sometimes two finger touches, but it almost always immediately segfaults with three or more. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 2 17:40:05 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Mon, 02 Sep 2013 15:40:05 +0000 Subject: [pypy-issue] [issue1593] segfault with ctypes callback on OS X In-Reply-To: <1378025729.36.0.512335519021.issue1593@bugs.pypy.org> Message-ID: <1378136405.78.0.352355450534.issue1593@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: Ah, I did not read correctly your first post: "MTDeviceStart spawns a new thread in which the callback is called" Indeed, pypy does not work well in this case. This is similar to https://bugs.pypy.org/issue1465 ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 2 17:51:49 2013 From: tracker at bugs.pypy.org (Florian Schulze) Date: Mon, 02 Sep 2013 15:51:49 +0000 Subject: [pypy-issue] [issue1465] cffi callback crashes in multithread environment In-Reply-To: <1366796639.81.0.357906871623.issue1465@bugs.pypy.org> Message-ID: <1378137109.36.0.805654226397.issue1465@bugs.pypy.org> Florian Schulze added the comment: I ran into a similar issue: https://bugs.pypy.org/issue1593 I love this project, but somehow every time I try something where pypy would be useful to me, it fails :( ---------- nosy: +fschulze ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 2 22:37:35 2013 From: tracker at bugs.pypy.org (mattip) Date: Mon, 02 Sep 2013 20:37:35 +0000 Subject: [pypy-issue] [issue1532] Running ipython with pypy on windows In-Reply-To: <1373550270.76.0.0364406526498.issue1532@bugs.pypy.org> Message-ID: <1378154255.24.0.56959905304.issue1532@bugs.pypy.org> mattip added the comment: fixed in changeset 9e7bb222d72f ---------- status: in-progress -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 3 10:02:44 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Tue, 03 Sep 2013 08:02:44 +0000 Subject: [pypy-issue] [issue1465] cffi callback crashes in multithread environment In-Reply-To: <1366796639.81.0.357906871623.issue1465@bugs.pypy.org> Message-ID: <1378195364.38.0.263316266538.issue1465@bugs.pypy.org> Armin Rigo added the comment: Argh! Found out the reason for why it crashes. It's only because the GIL was not initialized. In the example I tried, adding the following line at the top of the script helps a lot: import thread; thread.start_new_thread(lambda: None, ()) ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 3 12:07:11 2013 From: tracker at bugs.pypy.org (Florian Schulze) Date: Tue, 03 Sep 2013 10:07:11 +0000 Subject: [pypy-issue] [issue1465] cffi callback crashes in multithread environment In-Reply-To: <1366796639.81.0.357906871623.issue1465@bugs.pypy.org> Message-ID: <1378202831.45.0.694614804795.issue1465@bugs.pypy.org> Florian Schulze added the comment: Armins workaround works for me. I couldn't get it to crash so far. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 5 13:06:40 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 05 Sep 2013 11:06:40 +0000 Subject: [pypy-issue] [issue1465] cffi callback crashes in multithread environment In-Reply-To: <1366796639.81.0.357906871623.issue1465@bugs.pypy.org> Message-ID: <1378379200.51.0.993127746221.issue1465@bugs.pypy.org> Armin Rigo added the comment: Seems to be fixed by 0e638a269c11. ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 5 13:08:06 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 05 Sep 2013 11:08:06 +0000 Subject: [pypy-issue] [issue1593] segfault with ctypes callback on OS X In-Reply-To: <1378025729.36.0.512335519021.issue1593@bugs.pypy.org> Message-ID: <1378379286.21.0.249162912939.issue1593@bugs.pypy.org> Armin Rigo added the comment: Seems to be fixed by 0e638a269c11. Feel free to re-open if not. ---------- nosy: +arigo status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 5 17:25:26 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 05 Sep 2013 15:25:26 +0000 Subject: [pypy-issue] [issue1531] Add OpenBSD specific paths to tkinter module. In-Reply-To: <1373281829.97.0.396025486941.issue1531@bugs.pypy.org> Message-ID: <1378394726.72.0.891966690756.issue1531@bugs.pypy.org> Armin Rigo added the comment: Some day, we'll want some slightly more clean and general fix (for Tk and for others too). For now, good enough. Applied... ---------- nosy: +arigo status: unread -> in-progress ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 5 21:19:47 2013 From: tracker at bugs.pypy.org (anatoly techtonik) Date: Thu, 05 Sep 2013 19:19:47 +0000 Subject: [pypy-issue] [issue723] bugs.pypy.org SSL certificate broken In-Reply-To: <1305571165.17.0.639528771326.issue723@bugs.pypy.org> Message-ID: <1378408787.12.0.0818049743208.issue723@bugs.pypy.org> anatoly techtonik added the comment: Is there a problem to provide additional IP for this server? It costs 1 EUR/month at http://www.server4you.net/vserver/ ---------- nosy: +techtonik ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 5 22:43:49 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 05 Sep 2013 20:43:49 +0000 Subject: [pypy-issue] [issue1594] Assertion error with pypy-stm and tornado In-Reply-To: <1378062039.39.0.547595908984.issue1594@bugs.pypy.org> Message-ID: <1378413829.92.0.960078033368.issue1594@bugs.pypy.org> Armin Rigo added the comment: The original bug was fixed in the meantime. Some other minor issue exists with the reporting of "Detected conficts:" from transaction.py. For now I've disabled it and it seems to work. Note that you need the "stmgc-c4" branch; the "stmgc-static-barrier" has been merged some time ago. ---------- nosy: +arigo status: unread -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 5 23:27:00 2013 From: tracker at bugs.pypy.org (Marco Squarcina) Date: Thu, 05 Sep 2013 21:27:00 +0000 Subject: [pypy-issue] [issue1595] Inconsistency between CPython an PyPy while using argparse with mutual exclusion In-Reply-To: <1378416420.28.0.370375525236.issue1595@bugs.pypy.org> Message-ID: <1378416420.28.0.370375525236.issue1595@bugs.pypy.org> New submission from Marco Squarcina : Dear PyPy community, today I found an inconsistency between CPython and PyPy while using the argparse module. The argparse method add_mutually_exclusive_group is used to create a mutually exclusive group of arguments, i.e. (from the doc) "[...] will make sure that only one of the arguments in the mutually exclusive group was present on the command line". The attached source file behaves differently when executed with python and pypy. It has been tested with python-2.7.3, python-2.7.5, pypy-2.0 and pypy-2.1. An example follows: $ python parse.py -a 2 -b 7.3 usage: parse.py [-h] [-a A | -b B] parse.py: error: argument -b: not allowed with argument -a $ python parse.py -a 2 -b 3.14 usage: parse.py [-h] [-a A | -b B] parse.py: error: argument -b: not allowed with argument -a $ pypy-c2.0 parse.py -a 2 -b 7.3 usage: parse.py [-h] [-a A | -b B] parse.py: error: argument -b: not allowed with argument -a $ pypy-c2.0 parse.py -a 2 -b 3.14 $ The last command does not produce any error. While the pypy behaviour may look odd, here is what happens when replacing line 7 with: group.add_argument('-b', type=int, default=3) $ python parse_int.py -a 2 -b 7 usage: parse_int.py [-h] [-a A | -b B] parse_int.py: error: argument -b: not allowed with argument -a $ python parse_int.py -a 2 -b 3 $ pypy-c2.0 parse_int.py -a 2 -b 7 usage: parse_int.py [-h] [-a A | -b B] parse_int.py: error: argument -b: not allowed with argument -a $ pypy-c2.0 parse_int.py -a 2 -b 3 $ In this case pypy behaves exactly like python. Thanks for all your great work! Kind regards, Marco ---------- files: parse.py messages: 6124 nosy: lavish, pypy-issue priority: bug release: 2.1 status: unread title: Inconsistency between CPython an PyPy while using argparse with mutual exclusion ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 6 00:04:54 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Thu, 05 Sep 2013 22:04:54 +0000 Subject: [pypy-issue] [issue1595] Inconsistency between CPython an PyPy while using argparse with mutual exclusion In-Reply-To: <1378416420.28.0.370375525236.issue1595@bugs.pypy.org> Message-ID: <1378418694.61.0.742625155572.issue1595@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: Yes, CPython behavior is odd when default=3. This is because of a misuse of the "is" operator in argparse.py, line 1783: if argument_values is not action.default: Now, when you pass -b 3, will the value be identical to action.default? This depends how the object int("3") is constructed. Here CPython caches small integers, and int("3") is 3. But int("1000") is not 1000. And CPython does not cache floats (even 0.0) PyPy is a bit different, and int(x) is x, always: http://pypy.readthedocs.org/en/latest/cpython_differences.html#object-identity-of-primitive-values-is-and-id If it's important, argparse should be rewritten to not rely on the identity of ints or floats. ---------- nosy: +amaury status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 6 10:30:17 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 06 Sep 2013 08:30:17 +0000 Subject: [pypy-issue] [issue1595] Inconsistency between CPython an PyPy while using argparse with mutual exclusion In-Reply-To: <1378416420.28.0.370375525236.issue1595@bugs.pypy.org> Message-ID: <1378456217.45.0.0986815812822.issue1595@bugs.pypy.org> Armin Rigo added the comment: Argh, good spot. Yes, I believe that it's clearly a misuse of the "is" operator. It should be fixed in argparse.py and sent as a CPython bug report for the next 2.7.x micro release (and possibly for CPython 3). ---------- nosy: +arigo ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 6 11:00:53 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 06 Sep 2013 09:00:53 +0000 Subject: [pypy-issue] [issue1595] Inconsistency between CPython an PyPy while using argparse with mutual exclusion In-Reply-To: <1378416420.28.0.370375525236.issue1595@bugs.pypy.org> Message-ID: <1378458053.93.0.138024372997.issue1595@bugs.pypy.org> Armin Rigo added the comment: http://bugs.python.org/issue18943 ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 6 17:46:11 2013 From: tracker at bugs.pypy.org (Skip Montanaro) Date: Fri, 06 Sep 2013 15:46:11 +0000 Subject: [pypy-issue] [issue1596] Curses mods for OpenSuSE 12.2 In-Reply-To: <1378482371.18.0.41097667652.issue1596@bugs.pypy.org> Message-ID: <1378482371.18.0.41097667652.issue1596@bugs.pypy.org> New submission from Skip Montanaro : Trying to build on OpenSuSE 12.2, I discovered two problems. One, the ncurses library is named "libncurses", not "libcurses". Two, the library is in /usr/lib64. This small patch solves both issues. ---------- files: fficurses.diff messages: 6128 nosy: pypy-issue, smontanaro priority: bug status: unread title: Curses mods for OpenSuSE 12.2 ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 6 19:36:14 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 06 Sep 2013 17:36:14 +0000 Subject: [pypy-issue] [issue1596] Curses mods for OpenSuSE 12.2 In-Reply-To: <1378482371.18.0.41097667652.issue1596@bugs.pypy.org> Message-ID: <1378488974.35.0.482186321495.issue1596@bugs.pypy.org> Armin Rigo added the comment: Thanks! Applied in 8dc8224d017a. ---------- nosy: +arigo status: unread -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 6 20:25:05 2013 From: tracker at bugs.pypy.org (Edd Barrett) Date: Fri, 06 Sep 2013 18:25:05 +0000 Subject: [pypy-issue] [issue1597] Tkinter needs a threaded tcl In-Reply-To: <1378491905.85.0.834923457141.issue1597@bugs.pypy.org> Message-ID: <1378491905.85.0.834923457141.issue1597@bugs.pypy.org> New submission from Edd Barrett : I notice that pypy needs a threaded tcl: $ ./pypy-c /tmp/world.py Traceback (most recent call last): File "app_main.py", line 72, in run_toplevel File "/tmp/world.py", line 28, in app.mainloop() File "/home/edd/research/pypy/lib-python/2.7/lib-tk/Tkinter.py", line 1017, in mainloop self.tk.mainloop(n) File "/home/edd/research/pypy/lib_pypy/_tkinter/app.py", line 378, in mainloop raise NotImplementedError("TCL configured without threads") NotImplementedError: TCL configured without threads This error is produced when running the hello world example from here: http://docs.python.org/2/library/tkinter.html#a-simple-hello-world-program cpython is happy to run this program with a non-threaded tcl. Cheers ---------- messages: 6130 nosy: pypy-issue, vext01 priority: bug status: unread title: Tkinter needs a threaded tcl ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 6 20:32:29 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 06 Sep 2013 18:32:29 +0000 Subject: [pypy-issue] [issue1597] Tkinter needs a threaded tcl In-Reply-To: <1378491905.85.0.834923457141.issue1597@bugs.pypy.org> Message-ID: <1378492349.78.0.933117842467.issue1597@bugs.pypy.org> Armin Rigo added the comment: Looks like it was not implemented. We need to copy CPython's _tkinter.c for details about how it's supposed to be implemented. Testing it is going to be "fun" because we'd need to build a custom non-thread version of TCL. ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 7 15:58:00 2013 From: tracker at bugs.pypy.org (kostia.lopuhin) Date: Sat, 07 Sep 2013 13:58:00 +0000 Subject: [pypy-issue] [issue1594] Assertion error with pypy-stm and tornado In-Reply-To: <1378062039.39.0.547595908984.issue1594@bugs.pypy.org> Message-ID: <1378562280.17.0.617056884635.issue1594@bugs.pypy.org> kostia.lopuhin added the comment: Right now (92cab05fc583, Sep 07 2013, 12:07:47) it still fails for me but with a different error: pypy: /home/kostia/pypy/rpython/translator/stm/src_stm/et.c:147: stm_DirectReadBarrier: Assertion `(P->h_tid & GCFLAG_PUBLIC) || (P_prev->h_tid & GCFLAG_MOVED)' failed. Aborted (core dumped) I will try later :) Really inspiring to read STM-progress reports! ---------- status: resolved -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 7 21:42:34 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 07 Sep 2013 19:42:34 +0000 Subject: [pypy-issue] [issue1594] Assertion error with pypy-stm and tornado In-Reply-To: <1378062039.39.0.547595908984.issue1594@bugs.pypy.org> Message-ID: <1378582954.8.0.967078521635.issue1594@bugs.pypy.org> Armin Rigo added the comment: Sorry, today some intermediate state might have been broken. I tested your use case again with bd5b23f0f700, and it seems to work for me. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 7 23:12:39 2013 From: tracker at bugs.pypy.org (kostia.lopuhin) Date: Sat, 07 Sep 2013 21:12:39 +0000 Subject: [pypy-issue] [issue1594] Assertion error with pypy-stm and tornado In-Reply-To: <1378062039.39.0.547595908984.issue1594@bugs.pypy.org> Message-ID: <1378588359.21.0.0753604206572.issue1594@bugs.pypy.org> kostia.lopuhin added the comment: Yes, works fine now! Now I will try to see why it does not scale :) Thank you ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 8 00:51:38 2013 From: tracker at bugs.pypy.org (Isaac Freeman) Date: Sat, 07 Sep 2013 22:51:38 +0000 Subject: [pypy-issue] [issue1589] numpy: Structured arrays give odd behavior In-Reply-To: <1377313189.98.0.193986333307.issue1589@bugs.pypy.org> Message-ID: <1378594298.74.0.273118131915.issue1589@bugs.pypy.org> Isaac Freeman added the comment: Just thought I'd try this out in the latest hg HEAD and it seems the string fill segfault issue is fixed. >>>> import numpypy >>>> import numpy >>>> a = numpy.empty((10,10), dtype='S1') >>>> a.fill(' ') >>>> a array([[' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '], [' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '], [' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '], [' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '], [' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '], [' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '], [' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '], [' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '], [' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '], [' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ']], dtype='|S1') However, still getting odd, unprintable characters with the original example. Would you like me to open a separate bug for that or are you just tracking it here? ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 8 10:39:39 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 08 Sep 2013 08:39:39 +0000 Subject: [pypy-issue] [issue1595] Inconsistency between CPython an PyPy while using argparse with mutual exclusion In-Reply-To: <1378416420.28.0.370375525236.issue1595@bugs.pypy.org> Message-ID: <1378629579.33.0.138237620821.issue1595@bugs.pypy.org> Armin Rigo added the comment: CPython is at fault there, because it's inconsistent: if you take your example with "default=3" and replace it with "default=3000", you'll see that the behavior of CPython changes. We'll wait until http://bugs.python.org/issue18943 is resolved one way or another and then, as necessary, import the fix. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 8 20:24:24 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Sun, 08 Sep 2013 18:24:24 +0000 Subject: [pypy-issue] [issue1597] Tkinter needs a threaded tcl In-Reply-To: <1378491905.85.0.834923457141.issue1597@bugs.pypy.org> Message-ID: <1378664664.1.0.469644660536.issue1597@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: It's not difficult to do, but tedious. When tcl is not threaded, a lock needs to be acquired/released for all tcl operations. See all the "ENTER_TCL" macros in _tkinter.c. In our implementation, this could be replaced by a "with self._lock_tcl():" block, which would be a no-op when tcl is threaded. At least with cffi we don't have to bother about the GIL (and Py_BEGIN_ALLOW_THREADS and the tcl_tstate variable) ---------- nosy: +amaury ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 8 21:51:26 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Sun, 08 Sep 2013 19:51:26 +0000 Subject: [pypy-issue] [issue1597] Tkinter needs a threaded tcl In-Reply-To: <1378491905.85.0.834923457141.issue1597@bugs.pypy.org> Message-ID: <1378669886.58.0.120159415056.issue1597@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: Fixed with a2cfb94ccff5. I copied the "with lock" statements from CPython (ENTER_TCL and ENTER_PYTHON), at least for all functions that we implement. ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 10 00:48:11 2013 From: tracker at bugs.pypy.org (hpaulj) Date: Mon, 09 Sep 2013 22:48:11 +0000 Subject: [pypy-issue] [issue1595] Inconsistency between CPython an PyPy while using argparse with mutual exclusion In-Reply-To: <1378416420.28.0.370375525236.issue1595@bugs.pypy.org> Message-ID: <1378766891.01.0.530639550365.issue1595@bugs.pypy.org> hpaulj added the comment: I (as paul.j3) have proposed a patch in http://bugs.python.org/issue18943 that replaces the 'is not action.default' test. Instead it makes note in `_get_values()` of when it actually sets:`value = action.default`. Simply being equal to the default (whether according to `==` or `is`) is not enough. This should make the behavior consistent across implementations. There is a quite a backlog of proposed patches for argparse on CPython, so it might be some time before this, or some other fix, is approved. ---------- nosy: +hpaulj ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 10 22:59:37 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Tue, 10 Sep 2013 20:59:37 +0000 Subject: [pypy-issue] [issue1595] Inconsistency between CPython an PyPy while using argparse with mutual exclusion In-Reply-To: <1378416420.28.0.370375525236.issue1595@bugs.pypy.org> Message-ID: <1378846777.96.0.649493554634.issue1595@bugs.pypy.org> Armin Rigo added the comment: As the proposed patch changes the semantics, it might not get backported to 2.7. So I just wrote some "bug-to-bug" compatibility logic in 7d4e13193892. ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 11 12:54:30 2013 From: tracker at bugs.pypy.org (sn6uv) Date: Wed, 11 Sep 2013 10:54:30 +0000 Subject: [pypy-issue] [issue1491] raw_input incorrectly places cursor when given escape sequences In-Reply-To: <1369209820.42.0.70338361307.issue1491@bugs.pypy.org> Message-ID: <1378896870.59.0.905193419809.issue1491@bugs.pypy.org> sn6uv <16sn6uv at gmail.com> added the comment: Workaround: wrap the ANSI colour sequences in \001, \002 For the example above >>> raw_input('\001\033[31m\002>>> \001\033[39m\002') Confirmed for 2.1.0 also: $pypy --version ~ Python 2.7.3 (480845e6b1dd219d0944e30f62b01da378437c6c, Aug 08 2013, 17:02:19) [PyPy 2.1.0 with GCC 4.8.1 20130725 (prerelease)] ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 11 16:15:10 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Wed, 11 Sep 2013 14:15:10 +0000 Subject: [pypy-issue] [issue1491] raw_input incorrectly places cursor when given escape sequences In-Reply-To: <1369209820.42.0.70338361307.issue1491@bugs.pypy.org> Message-ID: <1378908910.11.0.576944824832.issue1491@bugs.pypy.org> Armin Rigo added the comment: Would it be useful if we recognize a few escape sequences manually? I'm thinking about sequences that start with "\033[" and that end with a letter. ---------- nosy: +arigo ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 11 18:19:21 2013 From: tracker at bugs.pypy.org (benma) Date: Wed, 11 Sep 2013 16:19:21 +0000 Subject: [pypy-issue] [issue1598] Multiplication of np.ndarray with a Python int or float results in loss of dtype In-Reply-To: <1378916361.75.0.325559638918.issue1598@bugs.pypy.org> Message-ID: <1378916361.75.0.325559638918.issue1598@bugs.pypy.org> New submission from benma : Hi a = np.array([1,2,3], dtype=np.int16) # outputs dtype('int64') instead of dtype('int16') print (a*2).dtype Same thing happens with floats. dtype is resetted to the default dtype, 64 bits on my machine. numpy on CPython keeps the original dtype. I ran into this bug when I used (a*2) as an input to a C function and the size (in bytes) of each element doubled. Best, Marko ---------- messages: 6143 nosy: benma, pypy-issue priority: bug release: 2.1 status: unread title: Multiplication of np.ndarray with a Python int or float results in loss of dtype ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 11 19:10:43 2013 From: tracker at bugs.pypy.org (Antonio Cuni) Date: Wed, 11 Sep 2013 17:10:43 +0000 Subject: [pypy-issue] [issue1599] quadratic time in list.extend(sometuple) In-Reply-To: <1378919443.8.0.0332374191379.issue1599@bugs.pypy.org> Message-ID: <1378919443.8.0.0332374191379.issue1599@bugs.pypy.org> New submission from Antonio Cuni : The functions filltable in the following snippet takes O(N**2) to complete, as shown by the example. If we turn tup into a list, it takes O(N). import time def filltable(N): table = [] tup = (1, 2, 'foo') for i in range(N): table.extend(tup) return table for i in range(0, 100): a = time.time() filltable(i*1000) b = time.time() print '%4d %.2f' % (i, b-a) ---------- messages: 6144 nosy: pypy-issue priority: performance bug status: unread title: quadratic time in list.extend(sometuple) ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 11 19:48:48 2013 From: tracker at bugs.pypy.org (Antonio Cuni) Date: Wed, 11 Sep 2013 17:48:48 +0000 Subject: [pypy-issue] [issue1599] quadratic time in list.extend(sometuple) In-Reply-To: <1378919443.8.0.0332374191379.issue1599@bugs.pypy.org> Message-ID: <1378921728.75.0.490662644172.issue1599@bugs.pypy.org> Antonio Cuni added the comment: after a quick look, I think the problem might be in ListStrategy._extend_from_iterable, which shrinks the list at the end, thus forcing a new resize at the next iteration of the loop ---------- status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 11 19:49:27 2013 From: tracker at bugs.pypy.org (Alex Gaynor) Date: Wed, 11 Sep 2013 17:49:27 +0000 Subject: [pypy-issue] [issue1599] quadratic time in list.extend(sometuple) In-Reply-To: <1378919443.8.0.0332374191379.issue1599@bugs.pypy.org> Message-ID: <1378921767.48.0.781264861093.issue1599@bugs.pypy.org> Alex Gaynor added the comment: I agree, shrinking the list seems unnecesary. ---------- nosy: +agaynor ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 11 23:21:12 2013 From: tracker at bugs.pypy.org (Philip Jenvey) Date: Wed, 11 Sep 2013 21:21:12 +0000 Subject: [pypy-issue] [issue1600] py3k: merge over uuid & argparse changes from default In-Reply-To: <1378934472.33.0.785041988609.issue1600@bugs.pypy.org> Message-ID: <1378934472.33.0.785041988609.issue1600@bugs.pypy.org> New submission from Philip Jenvey : A reminder for myself: uuid.py was modified in the merge commit c1f9cb9361f6, argparse.py in 927908bea004. These changes need to be brought over to py3k ---------- assignedto: pjenvey messages: 6147 nosy: pypy-issue priority: bug status: unread title: py3k: merge over uuid & argparse changes from default ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 12 00:46:39 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Wed, 11 Sep 2013 22:46:39 +0000 Subject: [pypy-issue] [issue1601] AssertionError: ('mixing pointer type <* Array of INT > with something else SomePBC(can_be_None=True, const=None, subset_of=None) In-Reply-To: <1378939599.82.0.448389003727.issue1601@bugs.pypy.org> Message-ID: <1378939599.82.0.448389003727.issue1601@bugs.pypy.org> New submission from Greg Czajkowski : Full traceback attached [translation:ERROR] AssertionError: ('mixing pointer type <* Array of INT > with something else SomePBC(can_be_None=True, const=None, subset_of=None)', < [translation:ERROR] Occurred processing the following simple_call: [translation:ERROR] (KeyError getting at the binding!) [translation:ERROR] v300 = simple_call((function _unicode2rawwcharp_loop), u_0, v299) [translation:ERROR] In : [translation:ERROR] Happened at file /path/pypy/pypy/module/_codecs/locale.py line 120 [translation:ERROR] [translation:ERROR] size = _unicode2rawwcharp_loop(u, None) if MERGE_SURROGATES else len(u) [translation:ERROR] array = lltype.malloc(RAW_WCHARP.TO, size + 1, flavor='raw') [translation:ERROR] array[size] = rffi.cast(rffi.WCHAR_T, u'\x00') [translation:ERROR] ==> _unicode2rawwcharp_loop(u, array) [translation:ERROR] [translation:ERROR] Known variable annotations: [translation:ERROR] u_0 = SomeUnicodeString() [translation:ERROR] v299 = SomePtr(ll_ptrtype=<* Array of INT >)>) [translation:ERROR] Processing block: [translation:ERROR] block at 15 is a [translation:ERROR] in (pypy.module._codecs.locale:115)unicode2rawwcharp [translation:ERROR] containing the following operations: [translation:ERROR] v301 = simple_call((function _unicode2rawwcharp_loop), u_0, (None)) [translation:ERROR] v302 = add(v301, (1)) [translation:ERROR] v299 = call_args((function malloc), ((2, ('flavor',), False, False)), (Array array), v302, ('raw')) [translation:ERROR] v303 = simple_call((function force_cast), (Number INT), (u'\x00')) [translation:ERROR] v304 = setitem(v299, v301, v303) [translation:ERROR] v300 = simple_call((function _unicode2rawwcharp_loop), u_0, v299) [translation:ERROR] --end-- ---------- files: traceback.txt messages: 6148 nosy: gcflymoto, pypy-issue priority: bug release: 2.1 status: unread title: AssertionError: ('mixing pointer type <* Array of INT > with something else SomePBC(can_be_None=True, const=None, subset_of=None) ________________________________________ PyPy bug tracker ________________________________________ -------------- next part -------------- n:ERROR] Error: [translation:ERROR] Traceback (most recent call last): [translation:ERROR] File "/path/pypy/rpython/translator/goal/translate.py", line 316, in main [translation:ERROR] drv.proceed(goals) [translation:ERROR] File "/path/pypy/rpython/translator/driver.py", line 534, in proceed [translation:ERROR] return self._execute(goals, task_skip = self._maybe_skip()) [translation:ERROR] File "/path/pypy/rpython/translator/tool/taskengine.py", line 114, in _execute [translation:ERROR] res = self._do(goal, taskcallable, *args, **kwds) [translation:ERROR] File "/path/pypy/rpython/translator/driver.py", line 283, in _do [translation:ERROR] res = func() [translation:ERROR] File "/path/pypy/rpython/translator/driver.py", line 320, in task_annotate [translation:ERROR] s = annotator.build_types(self.entry_point, self.inputtypes) [translation:ERROR] File "/path/pypy/rpython/annotator/annrpython.py", line 92, in build_types [translation:ERROR] return self.build_graph_types(flowgraph, inputcells, complete_now=complete_now) [translation:ERROR] File "/path/pypy/rpython/annotator/annrpython.py", line 148, in build_graph_types [translation:ERROR] self.complete() [translation:ERROR] File "/path/pypy/rpython/annotator/annrpython.py", line 202, in complete [translation:ERROR] self.complete_pending_blocks() [translation:ERROR] File "/path/pypy/rpython/annotator/annrpython.py", line 197, in complete_pending_blocks [translation:ERROR] self.processblock(graph, block) [translation:ERROR] File "/path/pypy/rpython/annotator/annrpython.py", line 347, in processblock [translation:ERROR] self.flowin(graph, block) [translation:ERROR] File "/path/pypy/rpython/annotator/annrpython.py", line 411, in flowin [translation:ERROR] self.consider_op(block, i) [translation:ERROR] File "/path/pypy/rpython/annotator/annrpython.py", line 605, in consider_op [translation:ERROR] resultcell = consider_meth(*argcells) [translation:ERROR] File "<2921-codegen /path/pypy/rpython/annotator/annrpython.py:645>", line 3, in consider_op_simple_call [translation:ERROR] return arg.simple_call(*args) [translation:ERROR] File "/path/pypy/rpython/annotator/unaryop.py", line 155, in simple_call [translation:ERROR] return obj.call(getbookkeeper().build_args("simple_call", args_s)) [translation:ERROR] File "/path/pypy/rpython/annotator/unaryop.py", line 736, in call [translation:ERROR] return bookkeeper.pbc_call(pbc, args) [translation:ERROR] File "/path/pypy/rpython/annotator/bookkeeper.py", line 657, in pbc_call [translation:ERROR] results.append(desc.pycall(schedule, args, s_previous_result, op)) [translation:ERROR] File "/path/pypy/rpython/annotator/description.py", line 306, in pycall [translation:ERROR] result = schedule(graph, inputcells) [translation:ERROR] File "/path/pypy/rpython/annotator/bookkeeper.py", line 653, in schedule [translation:ERROR] return self.annotator.recursivecall(graph, whence, inputcells) [translation:ERROR] File "/path/pypy/rpython/annotator/annrpython.py", line 293, in recursivecall [translation:ERROR] self.addpendingblock(graph, graph.startblock, inputcells) [translation:ERROR] File "/path/pypy/rpython/annotator/annrpython.py", line 190, in addpendingblock [translation:ERROR] self.mergeinputargs(graph, block, cells) [translation:ERROR] File "/path/pypy/rpython/annotator/annrpython.py", line 384, in mergeinputargs [translation:ERROR] unions = [annmodel.unionof(c1,c2) for c1, c2 in zip(oldcells,inputcells)] [translation:ERROR] File "/path/pypy/rpython/annotator/model.py", line 696, in unionof [translation:ERROR] s1 = pair(s1, s2).union() [translation:ERROR] File "/path/pypy/rpython/annotator/binaryop.py", line 908, in union [translation:ERROR] return pair(p2, obj).union() [translation:ERROR] File "/path/pypy/rpython/annotator/binaryop.py", line 898, in union [translation:ERROR] assert False, ("mixing pointer type %r with something else %r" % (p.ll_ptrtype, obj)) [translation:ERROR] AssertionError: ('mixing pointer type <* Array of INT > with something else SomePBC(can_be_None=True, const=None, subset_of=None)', < [translation:ERROR] Occurred processing the following simple_call: [translation:ERROR] (KeyError getting at the binding!) [translation:ERROR] v300 = simple_call((function _unicode2rawwcharp_loop), u_0, v299) [translation:ERROR] In : [translation:ERROR] Happened at file /path/pypy/pypy/module/_codecs/locale.py line 120 [translation:ERROR] [translation:ERROR] size = _unicode2rawwcharp_loop(u, None) if MERGE_SURROGATES else len(u) [translation:ERROR] array = lltype.malloc(RAW_WCHARP.TO, size + 1, flavor='raw') [translation:ERROR] array[size] = rffi.cast(rffi.WCHAR_T, u'\x00') [translation:ERROR] ==> _unicode2rawwcharp_loop(u, array) [translation:ERROR] [translation:ERROR] Known variable annotations: [translation:ERROR] u_0 = SomeUnicodeString() [translation:ERROR] v299 = SomePtr(ll_ptrtype=<* Array of INT >)>) [translation:ERROR] Processing block: [translation:ERROR] block at 15 is a [translation:ERROR] in (pypy.module._codecs.locale:115)unicode2rawwcharp [translation:ERROR] containing the following operations: [translation:ERROR] v301 = simple_call((function _unicode2rawwcharp_loop), u_0, (None)) [translation:ERROR] v302 = add(v301, (1)) [translation:ERROR] v299 = call_args((function malloc), ((2, ('flavor',), False, False)), (Array array), v302, ('raw')) [translation:ERROR] v303 = simple_call((function force_cast), (Number INT), (u'\x00')) [translation:ERROR] v304 = setitem(v299, v301, v303) [translation:ERROR] v300 = simple_call((function _unicode2rawwcharp_loop), u_0, v299) [translation:ERROR] --end-- From tracker at bugs.pypy.org Thu Sep 12 00:58:22 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Wed, 11 Sep 2013 22:58:22 +0000 Subject: [pypy-issue] [issue1601] AssertionError: ('mixing pointer type <* Array of INT > with something else SomePBC(can_be_None=True, const=None, subset_of=None) In-Reply-To: <1378939599.82.0.448389003727.issue1601@bugs.pypy.org> Message-ID: <1378940302.28.0.243284017576.issue1601@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: Please give more context. This code is from a py3k branch, but which version did you translate? With with Python on which OS? ---------- nosy: +amaury status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 12 01:04:44 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Wed, 11 Sep 2013 23:04:44 +0000 Subject: [pypy-issue] [issue1601] AssertionError: ('mixing pointer type <* Array of INT > with something else SomePBC(can_be_None=True, const=None, subset_of=None) In-Reply-To: <1378939599.82.0.448389003727.issue1601@bugs.pypy.org> Message-ID: <1378940684.27.0.584434131263.issue1601@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: Oh, let me guess: the Python used for translation has sys.maxunicode=65536. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 12 01:07:11 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Wed, 11 Sep 2013 23:07:11 +0000 Subject: [pypy-issue] [issue1601] AssertionError: ('mixing pointer type <* Array of INT > with something else SomePBC(can_be_None=True, const=None, subset_of=None) In-Reply-To: <1378939599.82.0.448389003727.issue1601@bugs.pypy.org> Message-ID: <1378940831.14.0.861459663039.issue1601@bugs.pypy.org> Greg Czajkowski added the comment: Yes. sys.maxunicode==65536.. the repo doesn't support building with python3 ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 12 01:08:14 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Wed, 11 Sep 2013 23:08:14 +0000 Subject: [pypy-issue] [issue1601] AssertionError: ('mixing pointer type <* Array of INT > with something else SomePBC(can_be_None=True, const=None, subset_of=None) In-Reply-To: <1378939599.82.0.448389003727.issue1601@bugs.pypy.org> Message-ID: <1378940894.35.0.232781203386.issue1601@bugs.pypy.org> Greg Czajkowski added the comment: More context... SUSE10 python 2.7.2 ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 12 01:15:44 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Wed, 11 Sep 2013 23:15:44 +0000 Subject: [pypy-issue] [issue1601] AssertionError: ('mixing pointer type <* Array of INT > with something else SomePBC(can_be_None=True, const=None, subset_of=None) In-Reply-To: <1378939599.82.0.448389003727.issue1601@bugs.pypy.org> Message-ID: <1378941344.41.0.333634696829.issue1601@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: it's an issue in pypy/module/_codecs/locale.py As a temporary workaround, you can try to modify this file, and set MERGE_SURROGATES = False To pjenvey: the "if we_are_translated()" logic is broken: outside of a function, it's always False! ---------- assignedto: -> pjenvey ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 12 01:20:47 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Wed, 11 Sep 2013 23:20:47 +0000 Subject: [pypy-issue] [issue1601] AssertionError: ('mixing pointer type <* Array of INT > with something else SomePBC(can_be_None=True, const=None, subset_of=None) In-Reply-To: <1378939599.82.0.448389003727.issue1601@bugs.pypy.org> Message-ID: <1378941647.48.0.213116575098.issue1601@bugs.pypy.org> Greg Czajkowski added the comment: that worked. the translate will take several hours. will report back on the success ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 12 02:15:05 2013 From: tracker at bugs.pypy.org (Julio Pintos) Date: Thu, 12 Sep 2013 00:15:05 +0000 Subject: [pypy-issue] [issue1602] syslog broken in 2.1 In-Reply-To: <1378944905.44.0.399487076089.issue1602@bugs.pypy.org> Message-ID: <1378944905.44.0.399487076089.issue1602@bugs.pypy.org> New submission from Julio Pintos : I updated to pypy 2.1 using ppa in lauchpad. After importing syslog it fails while trying to compile some cddi file. Python 2.7.3 (2.1.0+dfsg-1~ppa2, Sep 10 2013, 20:11:06) [PyPy 2.1.0 with GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``running pypy-c translate.py is a bit like watching a thriller movie, it could die at any time because of the 32-bit 4GB limit of RAM'' >>>> import syslog Traceback (most recent call last): File "", line 1, in File "/usr/lib/pypy/lib_pypy/syslog.py", line 68, in lib = ffi.verify(""" File "/usr/lib/pypy/lib_pypy/cffi/api.py", line 311, in verify lib = self.verifier.load_library() File "/usr/lib/pypy/lib_pypy/cffi/verifier.py", line 68, in load_library self.compile_module() File "/usr/lib/pypy/lib_pypy/cffi/verifier.py", line 55, in compile_module self._write_source() File "/usr/lib/pypy/lib_pypy/cffi/verifier.py", line 117, in _write_source file = open(self.sourcefilename, 'w') IOError: [Errno 13] Permission denied: '/usr/lib/pypy/lib_pypy/__pycache__/_cffi__g7019d5d3xad93c709.c' >>>> In 2.0.2 Python 2.7.3 (2.0.2+dfsg-1~ppa1, May 22 2013, 11:26:59) [PyPy 2.0.2 with GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``A pink glittery rotating lambda'' >>>> import syslog >>>> As a workaround, I was able to create compiled files by importing syslog as root. But I'm not sure if I'm missing something after upgrade or if these files should be bundled. Sorry if this is not the place to post this ---------- messages: 6155 nosy: julio.pintos, pypy-issue priority: bug release: 2.1 status: unread title: syslog broken in 2.1 ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 12 02:24:13 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Thu, 12 Sep 2013 00:24:13 +0000 Subject: [pypy-issue] [issue1601] AssertionError: ('mixing pointer type <* Array of INT > with something else SomePBC(can_be_None=True, const=None, subset_of=None) In-Reply-To: <1378939599.82.0.448389003727.issue1601@bugs.pypy.org> Message-ID: <1378945453.42.0.222075528487.issue1601@bugs.pypy.org> Greg Czajkowski added the comment: A different error was thrown by gilanalysis.py .. I will open a separate ticket. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 12 02:28:22 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Thu, 12 Sep 2013 00:28:22 +0000 Subject: [pypy-issue] [issue1603] Exception: 'no_release_gil' function can release the GIL In-Reply-To: <1378945702.82.0.303632350502.issue1603@bugs.pypy.org> Message-ID: <1378945702.82.0.303632350502.issue1603@bugs.pypy.org> New submission from Greg Czajkowski : Context: head of repo with py3k branch, building with python2.7.2 on SUSE10. Had to apply workaround from issue1601 to make it this far. Full traceback attached [translation:ERROR] Exception: 'no_release_gil' function can release the GIL: [translation:ERROR] [GilAnalyzer] analyze_direct_call((rpython.rtyper.lltypesystem.rffi:2)ccall_fstat64__INT_statP tr): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((rpython.rtyper.lltypesystem.rffi:183)fstat64__Signed_statPt r_star_2): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((rpython.rtyper.module.ll_os_stat:350)os_fstat_llimpl): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((rpython.rlib.rmmap:438)MMap.file_size): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.module.mmap.interp_mmap:79)W_MMap.descr_size): True ---------- files: traceback2.txt messages: 6157 nosy: gcflymoto, pypy-issue priority: bug release: 2.1 status: unread title: Exception: 'no_release_gil' function can release the GIL ________________________________________ PyPy bug tracker ________________________________________ -------------- next part -------------- [Timer] Timings: [Timer] annotate --- 589.8 s [Timer] rtype_lltype --- 1276.2 s [Timer] pyjitpl_lltype --- 1145.8 s [Timer] backendopt_lltype --- 211.6 s [Timer] =========================================== [Timer] Total: --- 3223.4 s [translation:info] Error: [translation:info] File "/nfs/sc/proj/skx/skx_fe_workarea05/gczajkow/pypy/rpython/translator/goal/translate.py", line 318, in main [translation:info] drv.proceed(goals) [translation:info] File "/nfs/sc/proj/skx/skx_fe_workarea05/gczajkow/pypy/rpython/translator/driver.py", line 534, in proceed [translation:info] return self._execute(goals, task_skip = self._maybe_skip()) [translation:info] File "/nfs/sc/proj/skx/skx_fe_workarea05/gczajkow/pypy/rpython/translator/tool/taskengine.py", line 114, in _execute [translation:info] res = self._do(goal, taskcallable, *args, **kwds) [translation:info] File "/nfs/sc/proj/skx/skx_fe_workarea05/gczajkow/pypy/rpython/translator/driver.py", line 283, in _do [translation:info] res = func() [translation:info] File "/nfs/sc/proj/skx/skx_fe_workarea05/gczajkow/pypy/rpython/translator/driver.py", line 389, in task_backendopt_lltype [translation:info] backend_optimizations(self.translator) [translation:info] File "/nfs/sc/proj/skx/skx_fe_workarea05/gczajkow/pypy/rpython/translator/backendopt/all.py", line 142, in backend_optimizations [translation:info] gilanalysis.analyze(graphs, translator) [translation:info] File "/nfs/sc/proj/skx/skx_fe_workarea05/gczajkow/pypy/rpython/translator/backendopt/gilanalysis.py", line 55, in analyze [translation:info] " %s\n%s" % (func, err.getvalue())) [translation:ERROR] Exception: 'no_release_gil' function can release the GIL: [translation:ERROR] [GilAnalyzer] analyze_direct_call((rpython.rtyper.lltypesystem.rffi:2)ccall_fstat64__INT_statPtr): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((rpython.rtyper.lltypesystem.rffi:183)fstat64__Signed_statPtr_star_2): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((rpython.rtyper.module.ll_os_stat:350)os_fstat_llimpl): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((rpython.rlib.rmmap:438)MMap.file_size): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.module.mmap.interp_mmap:79)W_MMap.descr_size): True [translation:ERROR] [GilAnalyzer] analyze_indirect_call([, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ]): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.gateway:742)BuiltinCode1.fastcall_1): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.function:78)funccall__star_1): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.baseobjspace:949)call_function__star_1): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.descroperation:539)_invoke_comparison): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.descroperation:566)comparison_eq_impl): True [translation:ERROR] [GilAnalyzer] analyze_indirect_call([, , , , , , , , , , , , ]): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.multimethod:1)__mm_eq_0_perform_call): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.sliceobject:126)lt__Slice_Slice): True [translation:ERROR] [GilAnalyzer] analyze_indirect_call([, , , , , , , , , ]): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.multimethod:1)__mm_lt_0_perform_call): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.baseobjspace:1183)ObjSpace.getindex_w): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.objspace:620)getindex_w): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.slicetype:18)_eval_slice_index): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.sliceobject:24)W_SliceObject.indices3): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.sliceobject:72)W_SliceObject.indices4): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.bytearrayobject:56)getitem__Bytearray_Slice): True [translation:ERROR] [GilAnalyzer] analyze_indirect_call([, , , , , , ]): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.multimethod:1)__mm_getitem_0_perform_call): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.builtinshortcut:92)getitem__star_2): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.objspace:600)finditem): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.argument:155)Arguments._match_signature): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.argument:299)Arguments.parse_into_scope): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.pycode:220)PyCode.funcrun_obj): True [translation:ERROR] [GilAnalyzer] analyze_direct_call(dispatcher): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.function:65)Function.call_obj_args): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.descroperation:156)call_args): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.descroperation:138)get_and_call_function__star_2): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.descroperation:169)get): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.descroperation:138)get_and_call_function__star_0): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.builtinshortcut:92)next__star_1): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.baseobjspace:817)ObjSpace._unpackiterable_known_length_jitlook): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.baseobjspace:762)unpackiterable): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.objspace:426)fixedview__False): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.argument:84)Arguments._combine_starargs_wrapped): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.argument:24)Arguments.__init__): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.descroperation:138)get_and_call_function__star_1): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.objspace:538)getattr): True [translation:ERROR] [GilAnalyzer] analyze_indirect_call([, , , , , , ]): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.objspace:363)allocate_instance__W_DictMultiObject): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.dictmultiobject:46)allocate_and_init_instance): True [translation:ERROR] [GilAnalyzer] analyze_indirect_call([, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ]): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.mapdict:233)DevolvedDictTerminator._write_terminator): True [translation:ERROR] [GilAnalyzer] analyze_direct_call(dispatcher): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.mapdict:37)AbstractAttribute.write): True [translation:ERROR] [GilAnalyzer] analyze_indirect_call([, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ]): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.mapdict:31)AbstractAttribute.read): True [translation:ERROR] [GilAnalyzer] analyze_indirect_call([, , , , , , , , , < FunctionGraph of (pypy.objspace.std.mapdict:369)W_ObjectObjectSize5.getdictvalue at 0x2aaac14f6210>, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ]): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.typeobject:337)W_TypeObject._lookup_where): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.std.typeobject:360)W_TypeObject.lookup_where_with_method_cache): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((:2)lookup____bool__): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.objspace.descroperation:227)is_true): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.baseobjspace:1049)ObjSpace.exception_is_valid_obj_as_class_w): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.error:197)OperationError.normalize_exception): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.error:52)OperationError.setup_context): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.baseobjspace:1367)ObjSpace.unicode0_w): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.baseobjspace:1405)ObjSpace.fsdecode_w): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.interpreter.pycode:419)PyCode.get_repr): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((pypy.module.pypyjit.interp_jit:30)get_printable_location): True [translation:ERROR] [GilAnalyzer] analyze_indirect_call([, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ]): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((rpython.jit.metainterp.logger:118)LogOperations.repr_of_resop): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((rpython.jit.metainterp.logger:164)LogOperations._log_operations): True [translation:ERROR] [GilAnalyzer] analyze_direct_call((rpython.jit.metainterp.logger:15)Logger.log_loop): True [translation:ERROR] From tracker at bugs.pypy.org Thu Sep 12 09:36:52 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 12 Sep 2013 07:36:52 +0000 Subject: [pypy-issue] [issue1602] syslog broken in 2.1 In-Reply-To: <1378944905.44.0.399487076089.issue1602@bugs.pypy.org> Message-ID: <1378971412.17.0.0718461809449.issue1602@bugs.pypy.org> Armin Rigo added the comment: Thanks for the report. It's a PPA bug --- misinstallation. As a workaround, run pypy as root and import syslog once; it should be enough to fix the installation. I'll report this to launchpad's PPA. ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 12 10:01:42 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 12 Sep 2013 08:01:42 +0000 Subject: [pypy-issue] [issue1602] PPA: syslog broken in 2.1 In-Reply-To: <1378944905.44.0.399487076089.issue1602@bugs.pypy.org> Message-ID: <1378972902.48.0.0467250988048.issue1602@bugs.pypy.org> Armin Rigo added the comment: I registered on PPA, but even so I fail to figure out how to add a bug report. The list seems read-only. So I'll just complain here and that's it. ---------- status: chatting -> invalid title: syslog broken in 2.1 -> PPA: syslog broken in 2.1 ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 12 15:34:13 2013 From: tracker at bugs.pypy.org (Johnny Boy) Date: Thu, 12 Sep 2013 13:34:13 +0000 Subject: [pypy-issue] [issue1604] ** buffer overflow detected ***: /var/www/api/pypy/bin/pypy terminated In-Reply-To: <1378992853.13.0.610639275293.issue1604@bugs.pypy.org> Message-ID: <1378992853.13.0.610639275293.issue1604@bugs.pypy.org> New submission from Johnny Boy : After doing some stress test on using gunicorn + pypy + eventlet it crashes some requests. Application arguments: gunicorn -t 60 -w 2 --worker-connections 1000 --worker-class gunicorn.workers.geventlet.EventletWorker -b unix:/tmp/duego-api.sock Logged when worker crashes: *** buffer overflow detected ***: /var/www/api/pypy/bin/pypy terminated ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f7857c4c007] /lib/x86_64-linux-gnu/libc.so.6(+0x107f00)[0x7f7857c4af00] /lib/x86_64-linux-gnu/libc.so.6(+0x108fbe)[0x7f7857c4bfbe] /var/www/api/pypy/bin/pypy[0x7329a9] /var/www/api/pypy/bin/pypy[0x131ab75] /var/www/api/pypy/bin/pypy[0xc97291] /var/www/api/pypy/bin/pypy[0xc98498] [0x7f785366e550] ======= Memory map: ======== 00400000-01679000 r-xp 00000000 fc:00 3150307 /var/www/api/pypy/bin/pypy 01879000-0187a000 r--p 01279000 fc:00 3150307 /var/www/api/pypy/bin/pypy 0187a000-0315a000 rw-p 0127a000 fc:00 3150307 /var/www/api/pypy/bin/pypy 0315a000-0316c000 rw-p 00000000 00:00 0 03b4c000-049c7000 rw-p 00000000 00:00 0 [heap] 049c7000-0d4e4000 rw-p 00000000 00:00 0 [heap] 7f7853478000-7f7853778000 rwxp 00000000 00:00 0 7f7853778000-7f7853a79000 rw-p 00000000 00:00 0 7f7853a79000-7f7853a8e000 r-xp 00000000 fc:00 262188 /lib/x86_64-linux- gnu/libgcc_s.so.1 7f7853a8e000-7f7853c8d000 ---p 00015000 fc:00 262188 /lib/x86_64-linux- gnu/libgcc_s.so.1 7f7853c8d000-7f7853c8e000 r--p 00014000 fc:00 262188 /lib/x86_64-linux- gnu/libgcc_s.so.1 7f7853c8e000-7f7853c8f000 rw-p 00015000 fc:00 262188 /lib/x86_64-linux- gnu/libgcc_s.so.1 7f7853c8f000-7f7853d71000 r-xp 00000000 fc:00 3937159 /usr/lib/x86_64-linux- gnu/libstdc++.so.6.0.16 7f7853d71000-7f7853f70000 ---p 000e2000 fc:00 3937159 /usr/lib/x86_64-linux- gnu/libstdc++.so.6.0.16 7f7853f70000-7f7853f78000 r--p 000e1000 fc:00 3937159 /usr/lib/x86_64-linux- gnu/libstdc++.so.6.0.16 7f7853f78000-7f7853f7a000 rw-p 000e9000 fc:00 3937159 /usr/lib/x86_64-linux- gnu/libstdc++.so.6.0.16 7f7853f7a000-7f7853f8f000 rw-p 00000000 00:00 0 7f7853f8f000-7f78540d6000 r-xp 00000000 fc:00 3944477 /usr/lib/libgeos-3.2.2.so 7f78540d6000-7f78542d5000 ---p 00147000 fc:00 3944477 /usr/lib/libgeos-3.2.2.so 7f78542d5000-7f78542dc000 r--p 00146000 fc:00 3944477 /usr/lib/libgeos-3.2.2.so 7f78542dc000-7f78542dd000 rw-p 0014d000 fc:00 3944477 /usr/lib/libgeos-3.2.2.so 7f78542dd000-7f78542f7000 r-xp 00000000 fc:00 3944478 /usr/lib/libgeos_c.so.1.6.2 7f78542f7000-7f78544f6000 ---p 0001a000 fc:00 3944478 /usr/lib/libgeos_c.so.1.6.2 7f78544f6000-7f78544f7000 r--p 00019000 fc:00 3944478 /usr/lib/libgeos_c.so.1.6.2 7f78544f7000-7f78544f8000 rw-p 0001a000 fc:00 3944478 /usr/lib/libgeos_c.so.1.6.2 7f78544f8000-7f78544fb000 r-xp 00000000 fc:00 262451 /lib/x86_64-linux- gnu/libgpg-error.so.0.8.0 7f78544fb000-7f78546fa000 ---p 00003000 fc:00 262451 /lib/x86_64-linux- gnu/libgpg-error.so.0.8.0 7f78546fa000-7f78546fb000 r--p 00002000 fc:00 262451 /lib/x86_64-linux- gnu/libgpg-error.so.0.8.0 7f78546fb000-7f78546fc000 rw-p 00003000 fc:00 262451 /lib/x86_64-linux- gnu/libgpg-error.so.0.8.0 7f78546fc000-7f7854776000 r-xp 00000000 fc:00 262439 /lib/x86_64-linux- gnu/libgcrypt.so.11.7.0 7f7854776000-7f7854976000 ---p 0007a000 fc:00 262439 /lib/x86_64-linux- gnu/libgcrypt.so.11.7.0 7f7854976000-7f7854977000 r--p 0007a000 fc:00 262439 /lib/x86_64-linux- gnu/libgcrypt.so.11.7.0 7f7854977000-7f785497a000 rw-p 0007b000 fc:00 262439 /lib/x86_64-linux- gnu/libgcrypt.so.11.7.0 7f785497a000-7f7854acb000 r-xp 00000000 fc:00 3942660 /usr/lib/x86_64-linux- gnu/libxml2.so.2.7.8 7f7854acb000-7f7854cca000 ---p 00151000 fc:00 3942660 /usr/lib/x86_64-linux- gnu/libxml2.so.2.7.8 7f7854cca000-7f7854cd2000 r--p 00150000 fc:00 3942660 /usr/lib/x86_64-linux- gnu/libxml2.so.2.7.8 7f7854cd2000-7f7854cd4000 rw-p 00158000 fc:00 3942660 /usr/lib/x86_64-linux- gnu/libxml2.so.2.7.8 7f7854cd4000-7f7854cd5000 rw-p 00000000 00:00 0 7f7854cd5000-7f7854ce9000 r-xp 00000000 fc:00 3941648 /usr/lib/x86_64-linux- gnu/libexslt.so.0.8.15 7f7854ce9000-7f7854ee8000 ---p 00014000 fc:00 3941648 /usr/lib/x86_64-linux- gnu/libexslt.so.0.8.15 7f7854ee8000-7f7854ee9000 r--p 00013000 fc:00 3941648 /usr/lib/x86_64-linux- gnu/libexslt.so.0.8.15 7f7854ee9000-7f7854eea000 rw-p 00014000 fc:00 3941648 /usr/lib/x86_64-linux- gnu/libexslt.so.0.8.15 7f7854eea000-7f7854f24000 r-xp 00000000 fc:00 3941647 /usr/lib/x86_64-linux- gnu/libxslt.so.1.1.26 7f7854f24000-7f7855124000 ---p 0003a000 fc:00 3941647 /usr/lib/x86_64-linux- gnu/libxslt.so.1.1.26 7f7855124000-7f7855125000 r--p 0003a000 fc:00 3941647 /usr/lib/x86_64-linux- gnu/libxslt.so.1.1.26 7f7855125000-7f7855126000 rw-p 0003b000 fc:00 3941647 /usr/lib/x86_64-linux- gnu/libxslt.so.1.1.26 7f7855126000-7f785524e000 r-xp 00000000 fc:00 3415014 /var/www/api/pypy/site- packages/lxml/etree.pypy-20.so 7f785524e000-7f785544d000 ---p 00128000 fc:00 3415014 /var/www/api/pypy/site- packages/lxml/etree.pypy-20.so 7f785544d000-7f785544e000 r--p 00127000 fc:00 3415014 /var/www/api/pypy/site- packages/lxml/etree.pypy-20.so 7f785544e000-7f7855481000 rw-p 00128000 fc:00 3415014 /var/www/api/pypy/site- packages/lxml/etree.pypy-20.so 7f7855481000-7f7855486000 rw-p 00000000 00:00 0 7f7855486000-7f785548a000 r-xp 00000000 fc:00 262370 /lib/x86_64-linux- gnu/libuuid.so.1.3.0 7f785548a000-7f7855689000 ---p 00004000 fc:00 262370 /lib/x86_64-linux- gnu/libuuid.so.1.3.0 7f7855689000-7f785568a000 r--p 00003000 fc:00 262370 /lib/x86_64-linux- gnu/libuuid.so.1.3.0 7f785568a000-7f785568b000 rw-p 00004000 fc:00 262370 /lib/x86_64-linux- gnu/libuuid.so.1.3.0 7f785568b000-7f785569f000 r-xp 00000000 fc:00 3944678 /usr/lib/libmemcached.so.6.0.0 7f785569f000-7f785589e000 ---p 00014000 fc:00 3944678 /usr/lib/libmemcached.so.6.0.0 7f785589e000-7f785589f000 r--p 00013000 fc:00 3944678 /usr/lib/libmemcached.so.6.0.0 7f785589f000-7f78558a0000 rw-p 00014000 fc:00 3944678 /usr/lib/libmemcached.so.6.0.0 7f78558a0000-7f78558aa000 r-xp 00000000 fc:00 3157112 /var/www/api/pypy/site- packages/_pylibmc.pypy-20.so 7f78558aa000-7f7855aa9000 ---p 0000a000 fc:00 3157112 /var/www/api/pypy/site- packages/_pylibmc.pypy-20.so 7f7855aa9000-7f7855aaa000 r--p 00009000 fc:00 3157112 /var/www/api/pypy/site- packages/_pylibmc.pypy-20.so 7f7855aaa000-7f7855aab000 rw-p 0000a000 fc:00 3157112 /var/www/api/pypy/site- packages/_pylibmc.pypy-20.so 7f7855aab000-7f7855abb000 r-xp 00000000 fc:00 3415274 /var/www/api/pypy/site- packages/OpenSSL/crypto.pypy-20.so 7f7855abb000-7f7855cba000 ---p 00010000 fc:00 3415274 /var/www/api/pypy/site- packages/OpenSSL/crypto.pypy-20.so 7f7855cba000-7f7855cbb000 r--p 0000f000 fc:00 3415274 /var/www/api/pypy/site- packages/OpenSSL/crypto.pypy-20.so 7f7855cbb000-7f7855cc2000 rw-p 00010000 fc:00 3415274 /var/www/api/pypy/site- packages/OpenSSL/crypto.pypy-20.so 7f7855cc2000-7f7855fc8000 rw-p 00000000 00:00 0 7f7856049000-7f78561cc000 rw-p 00000000 00:00 0 7f78561cd000-7f78561cf000 r-xp 00000000 fc:00 3415276 /var/www/api/pypy/site- packages/OpenSSL/rand.pypy-20.so 7f78561cf000-7f78563ce000 ---p 00002000 fc:00 3415276 /var/www/api/pypy/site- packages/OpenSSL/rand.pypy-20.so 7f78563ce000-7f78563cf000 r--p 00001000 fc:00 3415276 /var/www/api/pypy/site- packages/OpenSSL/rand.pypy-20.so 7f78563cf000-7f78563d0000 rw-p 00002000 fc:00 3415276 /var/www/api/pypy/site- packages/OpenSSL/rand.pypy-20.so 7f78563d0000-7f78564d2000 rw-p 00000000 00:00 0 7f78564d4000-7f78565d4000 rwxp 00000000 00:00 0 7f78565d4000-7f78567d8000 rw-p 00000000 00:00 0 7f78567da000-7f78568da000 rwxp 00000000 00:00 0 7f78568da000-7f7856da3000 rw-p 00000000 00:00 0 7f7856da3000-7f7856ea3000 rwxp 00000000 00:00 0 7f7856f64000-7f7856fe5000 rw-p 00000000 00:00 0 7f7856fe5000-7f7856ff1000 r-xp 00000000 fc:00 262175 /lib/x86_64-linux- gnu/libnss_files-2.15.so 7f7856ff1000-7f78571f0000 ---p 0000c000 fc:00 262175 /lib/x86_64-linux- gnu/libnss_files-2.15.so 7f78571f0000-7f78571f1000 r--p 0000b000 fc:00 262175 /lib/x86_64-linux- gnu/libnss_files-2.15.so 7f78571f1000-7f78571f2000 rw-p 0000c000 fc:00 262175 /lib/x86_64-linux- gnu/libnss_files-2.15.so 7f78571f2000-7f78571fc000 r-xp 00000000 fc:00 262176 /lib/x86_64-linux- gnu/libnss_nis-2.15.so 7f78571fc000-7f78573fc000 ---p 0000a000 fc:00 262176 /lib/x86_64-linux- gnu/libnss_nis-2.15.so 7f78573fc000-7f78573fd000 r--p 0000a000 fc:00 262176 /lib/x86_64-linux- gnu/libnss_nis-2.15.so 7f78573fd000-7f78573fe000 rw-p 0000b000 fc:00 262176 /lib/x86_64-linux- gnu/libnss_nis-2.15.so 7f78573fe000-7f7857415000 r-xp 00000000 fc:00 262170 /lib/x86_64-linux- gnu/libnsl-2.15.so 7f7857415000-7f7857614000 ---p 00017000 fc:00 262170 /lib/x86_64-linux- gnu/libnsl-2.15.so 7f7857614000-7f7857615000 r--p 00016000 fc:00 262170 /lib/x86_64-linux- gnu/libnsl-2.15.so 7f7857615000-7f7857616000 rw-p 00017000 fc:00 262170 /lib/x86_64-linux- gnu/libnsl-2.15.so 7f7857616000-7f7857618000 rw-p 00000000 00:00 0 7f7857618000-7f7857620000 r-xp 00000000 fc:00 262178 /lib/x86_64-linux- gnu/libnss_compat-2.15.so 7f7857620000-7f785781f000 ---p 00008000 fc:00 262178 /lib/x86_64-linux- gnu/libnss_compat-2.15.so 7f785781f000-7f7857820000 r--p 00007000 fc:00 262178 /lib/x86_64-linux- gnu/libnss_compat-2.15.so 7f7857820000-7f7857821000 rw-p 00008000 fc:00 262178 /lib/x86_64-linux- gnu/libnss_compat-2.15.so 7f7857821000-7f7857b43000 rw-p 00000000 00:00 0 7f7857b43000-7f7857cf6000 r-xp 00000000 fc:00 262162 /lib/x86_64-linux-gnu/libc- 2.15.so 7f7857cf6000-7f7857ef5000 ---p 001b3000 fc:00 262162 /lib/x86_64-linux-gnu/libc- 2.15.so 7f7857ef5000-7f7857ef9000 r--p 001b2000 fc:00 262162 /lib/x86_64-linux-gnu/libc- 2.15.so 7f7857ef9000-7f7857efb000 rw-p 001b6000 fc:00 262162 /lib/x86_64-linux-gnu/libc- 2.15.so 7f7857efb000-7f7857f00000 rw-p 00000000 00:00 0 7f7857f00000-7f7857f18000 r-xp 00000000 fc:00 262186 /lib/x86_64-linux- gnu/libpthread-2.15.so 7f7857f18000-7f7858117000 ---p 00018000 fc:00 262186 /lib/x86_64-linux- gnu/libpthread-2.15.so 7f7858117000-7f7858118000 r--p 00017000 fc:00 262186 /lib/x86_64-linux- gnu/libpthread-2.15.so 7f7858118000-7f7858119000 rw-p 00018000 fc:00 262186 /lib/x86_64-linux- gnu/libpthread-2.15.so 7f7858119000-7f785811d000 rw-p 00000000 00:00 0 7f785811d000-7f785813f000 r-xp 00000000 fc:00 262212 /lib/x86_64-linux- gnu/libtinfo.so.5.9 7f785813f000-7f785833f000 ---p 00022000 fc:00 262212 /lib/x86_64-linux- gnu/libtinfo.so.5.9 7f785833f000-7f7858343000 r--p 00022000 fc:00 262212 /lib/x86_64-linux- gnu/libtinfo.so.5.9 7f7858343000-7f7858344000 rw-p 00026000 fc:00 262212 /lib/x86_64-linux- gnu/libtinfo.so.5.9 7f7858344000-7f785834d000 r-xp 00000000 fc:00 262177 /lib/x86_64-linux- gnu/libcrypt-2.15.so 7f785834d000-7f785854d000 ---p 00009000 fc:00 262177 /lib/x86_64-linux- gnu/libcrypt-2.15.so 7f785854d000-7f785854e000 r--p 00009000 fc:00 262177 /lib/x86_64-linux- gnu/libcrypt-2.15.so 7f785854e000-7f785854f000 rw-p 0000a000 fc:00 262177 /lib/x86_64-linux- gnu/libcrypt-2.15.so 7f785854f000-7f785857d000 rw-p 00000000 00:00 0 7f785857d000-7f785857f000 r-xp 00000000 fc:00 262179 /lib/x86_64-linux- gnu/libutil-2.15.so 7f785857f000-7f785877e000 ---p 00002000 fc:00 262179 /lib/x86_64-linux- gnu/libutil-2.15.so 7f785877e000-7f785877f000 r--p 00001000 fc:00 262179 /lib/x86_64-linux- gnu/libutil-2.15.so 7f785877f000-7f7858780000 rw-p 00002000 fc:00 262179 /lib/x86_64-linux- gnu/libutil-2.15.so 7f7858780000-7f785878f000 r-xp 00000000 fc:00 262149 /lib/x86_64-linux- gnu/libbz2.so.1.0.4 7f785878f000-7f785898e000 ---p 0000f000 fc:00 262149 /lib/x86_64-linux- gnu/libbz2.so.1.0.4 7f785898e000-7f785898f000 r--p 0000e000 fc:00 262149 /lib/x86_64-linux- gnu/libbz2.so.1.0.4 7f785898f000-7f7858990000 rw-p 0000f000 fc:00 262149 /lib/x86_64-linux- gnu/libbz2.so.1.0.4 7f7858990000-7f7858997000 r-xp 00000000 fc:00 262172 /lib/x86_64-linux-gnu/librt- 2.15.so 7f7858997000-7f7858b96000 ---p 00007000 fc:00 262172 /lib/x86_64-linux-gnu/librt- 2.15.so 7f7858b96000-7f7858b97000 r--p 00006000 fc:00 262172 /lib/x86_64-linux-gnu/librt- 2.15.so 7f7858b97000-7f7858b98000 rw-p 00007000 fc:00 262172 /lib/x86_64-linux-gnu/librt- 2.15.so 7f7858b98000-7f7858bbf000 r-xp 00000000 fc:00 262453 /lib/x86_64-linux- gnu/libexpat.so.1.5.2 7f7858bbf000-7f7858dbf000 ---p 00027000 fc:00 262453 /lib/x86_64-linux- gnu/libexpat.so.1.5.2 7f7858dbf000-7f7858dc1000 r--p 00027000 fc:00 262453 /lib/x86_64-linux- gnu/libexpat.so.1.5.2 7f7858dc1000-7f7858dc2000 rw-p 00029000 fc:00 262453 /lib/x86_64-linux- gnu/libexpat.so.1.5.2 7f7858dc2000-7f7858f61000 r-xp 00000000 fc:00 262339 /lib/x86_64-linux- gnu/libcrypto.so.1.0.0 7f7858f61000-7f7859160000 ---p 0019f000 fc:00 262339 /lib/x86_64-linux- gnu/libcrypto.so.1.0.0 7f7859160000-7f785917b000 r--p 0019e000 fc:00 262339 /lib/x86_64-linux- gnu/libcrypto.so.1.0.0 7f785917b000-7f7859186000 rw-p 001b9000 fc:00 262339 /lib/x86_64-linux- gnu/libcrypto.so.1.0.0 7f7859186000-7f785918a000 rw-p 00000000 00:00 0 7f785918a000-7f78591dc000 r-xp 00000000 fc:00 262338 /lib/x86_64-linux- gnu/libssl.so.1.0.0 7f78591dc000-7f78593dc000 ---p 00052000 fc:00 262338 /lib/x86_64-linux- gnu/libssl.so.1.0.0 7f78593dc000-7f78593df000 r--p 00052000 fc:00 262338 /lib/x86_64-linux- gnu/libssl.so.1.0.0 7f78593df000-7f78593e5000 rw-p 00055000 fc:00 262338 /lib/x86_64-linux- gnu/libssl.so.1.0.0 7f78593e5000-7f78593e6000 rw-p 00000000 00:00 0 7f78593e6000-7f78593fc000 r-xp 00000000 fc:00 262372 /lib/x86_64-linux- gnu/libz.so.1.2.3.4 7f78593fc000-7f78595fb000 ---p 00016000 fc:00 262372 /lib/x86_64-linux- gnu/libz.so.1.2.3.4 7f78595fb000-7f78595fc000 r--p 00015000 fc:00 262372 /lib/x86_64-linux- gnu/libz.so.1.2.3.4 7f78595fc000-7f78595fd000 rw-p 00016000 fc:00 262372 /lib/x86_64-linux- gnu/libz.so.1.2.3.4 7f78595fd000-7f7859604000 r-xp 00000000 fc:00 3933605 /usr/lib/x86_64-linux- gnu/libffi.so.6.0.0 7f7859604000-7f7859803000 ---p 00007000 fc:00 3933605 /usr/lib/x86_64-linux- gnu/libffi.so.6.0.0 7f7859803000-7f7859804000 r--p 00006000 fc:00 3933605 /usr/lib/x86_64-linux- gnu/libffi.so.6.0.0 7f7859804000-7f7859805000 rw-p 00007000 fc:00 3933605 /usr/lib/x86_64-linux- gnu/libffi.so.6.0.0 7f7859805000-7f78598fe000 r-xp 00000000 fc:00 262161 /lib/x86_64-linux-gnu/libm- 2.15.so 7f78598fe000-7f7859afd000 ---p 000f9000 fc:00 262161 /lib/x86_64-linux-gnu/libm- 2.15.so 7f7859afd000-7f7859afe000 r--p 000f8000 fc:00 262161 /lib/x86_64-linux-gnu/libm- 2.15.so 7f7859afe000-7f7859aff000 rw-p 000f9000 fc:00 262161 /lib/x86_64-linux-gnu/libm- 2.15.so 7f7859aff000-7f7859b01000 r-xp 00000000 fc:00 262182 /lib/x86_64-linux-gnu/libdl- 2.15.so 7f7859b01000-7f7859d01000 ---p 00002000 fc:00 262182 /lib/x86_64-linux-gnu/libdl- 2.15.so 7f7859d01000-7f7859d02000 r--p 00002000 fc:00 262182 /lib/x86_64-linux-gnu/libdl- 2.15.so 7f7859d02000-7f7859d03000 rw-p 00003000 fc:00 262182 /lib/x86_64-linux-gnu/libdl- 2.15.so 7f7859d03000-7f7859d25000 r-xp 00000000 fc:00 262166 /lib/x86_64-linux-gnu/ld- 2.15.so 7f7859d49000-7f7859d50000 r--s 00000000 fc:00 3934989 /usr/lib/x86_64-linux- gnu/gconv/gconv-modules.cache 7f7859d50000-7f7859f1c000 rw-p 00000000 00:00 0 7f7859f21000-7f7859f22000 rw-p 00000000 00:00 0 7f7859f22000-7f7859f23000 rwxp 00000000 00:00 0 7f7859f23000-7f7859f25000 rw-p 00000000 00:00 0 7f7859f25000-7f7859f26000 r--p 00022000 fc:00 262166 /lib/x86_64-linux-gnu/ld- 2.15.so 7f7859f26000-7f7859f28000 rw-p 00023000 fc:00 262166 /lib/x86_64-linux-gnu/ld- 2.15.so 7fffe5020000-7fffe5041000 rw-p 00000000 00:00 0 [stack] 7fffe519d000-7fffe519e000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Environment: Python 2.7.3 (2.1.0+dfsg-1~ppa2, Sep 10 2013, 20:11:06) [PyPy 2.1.0 with GCC 4.6.3] on linux2 Ubuntu 12.04 on Virtualbox 4.2.12. pip freeze: Babel==0.9.6 Flask==0.10.1 Flask-Babel==0.8 Jinja2==2.7 MarkupSafe==0.18 PyYAML==3.10 Pygments==1.6 Shapely==1.2.17 Werkzeug==0.8.3 amqp==1.0.11 amqplib==1.0.2 anyjson==0.3.3 argparse==1.2.1 beautifulsoup4==4.1.3 billiard==2.7.3.28 blinker==1.2 boto==2.6.0 celery==3.0.19 cffi==0.6 ctypes-configure==0.1 dnspython==1.11.0 docutils==0.10 eventlet==0.13.0 facebook-sdk==0.4.0 gcm-client==0.1.3 greenlet==0.4.0 gunicorn==18.0 itsdangerous==0.23 kombu==2.5.10 lxml==3.2.1 mock==1.0.1 mongoengine==0.7.8 newrelic==2.0.0.1 nose==1.3.0 py==1.4.14 pyOpenSSL==0.12 pycrypto==2.6 pylibmc==1.2.3 pymongo==2.5.1 pyprof2calltree==1.1.0 python-dateutil==1.5 python-gcm==0.1.4 python-memcached==1.48 pytz==2013d pyzmq==13.1.0 requests==1.2.3 speaklater==1.3 statsd==2.0.1 wsgiref==0.1.2 ---------- messages: 6160 nosy: balboah, pypy-issue priority: critical release: 2.1 status: unread title: ** buffer overflow detected ***: /var/www/api/pypy/bin/pypy terminated ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 13 14:23:00 2013 From: tracker at bugs.pypy.org (Edd Barrett) Date: Fri, 13 Sep 2013 12:23:00 +0000 Subject: [pypy-issue] [issue1605] __str__ is not RPython? In-Reply-To: <1379074980.89.0.971074200895.issue1605@bugs.pypy.org> Message-ID: <1379074980.89.0.971074200895.issue1605@bugs.pypy.org> New submission from Edd Barrett : Hi, I spent some time today working on a custom interpreter written in RPython. I was trying to figure out why my get_printable_location() was not calling __str__ upon instances. It seems that if you try to str() an instance in RPython, str() is ignored entirely and instead the generic str() is called. E.g. 'def get_printable_location(x): return str(x)' will not call __str__ upon x, but instead will print the generic string representation. If calling str() (and others?) is not RPython then perhaps an error should be thrown. If calling str() is RPython, then we have a bug? Can someone clarify? Thanks. ---------- messages: 6161 nosy: pypy-issue, vext01 priority: bug status: unread title: __str__ is not RPython? ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 13 14:49:34 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 13 Sep 2013 12:49:34 +0000 Subject: [pypy-issue] [issue1605] __str__ is not RPython? In-Reply-To: <1379074980.89.0.971074200895.issue1605@bugs.pypy.org> Message-ID: <1379076574.25.0.788675020824.issue1605@bugs.pypy.org> Armin Rigo added the comment: See documentation here: http://doc.pypy.org/en/latest/coding-guide.html#object-restrictions . Using str() on instances (for example via "print") is still useful for debugging, so preventing it altogether is not a good solution either. ---------- nosy: +arigo status: unread -> wontfix ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 13 19:54:16 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 13 Sep 2013 17:54:16 +0000 Subject: [pypy-issue] [issue1588] Fatal RPython error: AssertionError pypy-2.1 In-Reply-To: <1377239466.8.0.79610637264.issue1588@bugs.pypy.org> Message-ID: <1379094856.87.0.650653038755.issue1588@bugs.pypy.org> Armin Rigo added the comment: Yes, please include the DLL. You must give us all the files and instructions on how to run them, so that we can repeat the bug on our own machines. Otherwise, we cannot help at all. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 14 11:03:04 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 14 Sep 2013 09:03:04 +0000 Subject: [pypy-issue] [issue1604] ** buffer overflow detected ***: /var/www/api/pypy/bin/pypy terminated In-Reply-To: <1378992853.13.0.610639275293.issue1604@bugs.pypy.org> Message-ID: <1379149383.98.0.221707569235.issue1604@bugs.pypy.org> Armin Rigo added the comment: I did "pip install gunicorn" then copied your gunicorn line, but it seems to be incomplete, because I get the following error: usage: gunicorn [OPTIONS] [APP_MODULE] gunicorn: error: No application module specified. Please complete it into a working example. I cannot because I don't know gunicorn. ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 15 00:20:56 2013 From: tracker at bugs.pypy.org (Philip Jenvey) Date: Sat, 14 Sep 2013 22:20:56 +0000 Subject: [pypy-issue] [issue1599] quadratic time in list.extend(sometuple) In-Reply-To: <1378919443.8.0.0332374191379.issue1599@bugs.pypy.org> Message-ID: <1379197256.73.0.947857810599.issue1599@bugs.pypy.org> Philip Jenvey added the comment: The actual shrinking should only occur when a length_hint reported a greater size than the actual amount the list was extended by. Which should never happen w/ a plain tuple # cut back if the length hint was too large if extended < length_hint: w_list._resize_hint(w_list.length()) ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 15 00:35:48 2013 From: tracker at bugs.pypy.org (Philip Jenvey) Date: Sat, 14 Sep 2013 22:35:48 +0000 Subject: [pypy-issue] [issue1601] AssertionError: ('mixing pointer type <* Array of INT > with something else SomePBC(can_be_None=True, const=None, subset_of=None) In-Reply-To: <1378939599.82.0.448389003727.issue1601@bugs.pypy.org> Message-ID: <1379198148.65.0.665193203167.issue1601@bugs.pypy.org> Philip Jenvey added the comment: This should be solved in 4e8538d98f8d, thanks for the report ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 15 00:40:10 2013 From: tracker at bugs.pypy.org (Philip Jenvey) Date: Sat, 14 Sep 2013 22:40:10 +0000 Subject: [pypy-issue] [issue1603] Exception: 'no_release_gil' function can release the GIL In-Reply-To: <1378945702.82.0.303632350502.issue1603@bugs.pypy.org> Message-ID: <1379198410.98.0.0878596643435.issue1603@bugs.pypy.org> Philip Jenvey added the comment: I cannot currently reproduce this nor do the linux64 buildbots. This doesn't seem like a platform related error, either. Are you using any special translation options? What revision was this against (I'm guessing 927908bea004 by the date)? ---------- status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 15 04:44:04 2013 From: tracker at bugs.pypy.org (Philip Jenvey) Date: Sun, 15 Sep 2013 02:44:04 +0000 Subject: [pypy-issue] [issue1603] Exception: 'no_release_gil' function can release the GIL In-Reply-To: <1378945702.82.0.303632350502.issue1603@bugs.pypy.org> Message-ID: <1379213044.28.0.824637316378.issue1603@bugs.pypy.org> Philip Jenvey added the comment: I spoke too soon, this seems to occur with -Ojit, but not without the jit enabled (e.g. -O2) ---------- assignedto: -> pjenvey ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 15 05:40:56 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Sun, 15 Sep 2013 03:40:56 +0000 Subject: [pypy-issue] [issue1601] AssertionError: ('mixing pointer type <* Array of INT > with something else SomePBC(can_be_None=True, const=None, subset_of=None) In-Reply-To: <1378939599.82.0.448389003727.issue1601@bugs.pypy.org> Message-ID: <1379216456.5.0.338683555497.issue1601@bugs.pypy.org> Greg Czajkowski added the comment: solved. thanks. ---------- status: resolved -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 15 10:05:07 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 15 Sep 2013 08:05:07 +0000 Subject: [pypy-issue] [issue1606] Test failures In-Reply-To: <1379232307.33.0.259128845268.issue1606@bugs.pypy.org> Message-ID: <1379232307.33.0.259128845268.issue1606@bugs.pypy.org> New submission from Armin Rigo : This is a reminder for various people that there are various tests that have been failing, sometimes for a long time. (I might just go and skip the tests instead, say in 1-2 weeks; which is a bad practice, so I hope you'll do something before.) micronumpy.test.test_dtypes Shows one failure on 32-bit. test_pypy_c.test_thread Just fails. test__pypyjson, test_runicode, test_ucd Showed up recently on tannit32 once we upgraded to a Python 2.7 with sys.maxunicode == 65536. (I may have a look at the last two.) ---------- messages: 6170 nosy: arigo, pypy-issue priority: critical status: unread title: Test failures ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 16 21:19:51 2013 From: tracker at bugs.pypy.org (Philip Jenvey) Date: Mon, 16 Sep 2013 19:19:51 +0000 Subject: [pypy-issue] [issue1603] Exception: 'no_release_gil' function can release the GIL In-Reply-To: <1378945702.82.0.303632350502.issue1603@bugs.pypy.org> Message-ID: <1379359191.33.0.97788680216.issue1603@bugs.pypy.org> Philip Jenvey added the comment: Armin, can you shed some light on what the attached gilanalyzer output is trying to tell us? ---------- nosy: +arigo ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 17 14:26:22 2013 From: tracker at bugs.pypy.org (Johnny Boy) Date: Tue, 17 Sep 2013 12:26:22 +0000 Subject: [pypy-issue] [issue1607] Fatal error calling PyEval_SaveThread In-Reply-To: <1379420782.98.0.478846388508.issue1607@bugs.pypy.org> Message-ID: <1379420782.98.0.478846388508.issue1607@bugs.pypy.org> New submission from Johnny Boy : Not sure what extension that caused this exactly but after upgrading PyPy from 2.0 to 2.1 I get this sometimes: ------------------ Sep 17 14:22:35 +02:00 api13 [info] api: Fatal error in cpyext, CPython compatibility layer, calling PyEval_SaveThread Sep 17 14:22:35 +02:00 api13 [info] api: Either report a bug or consider not using this particular extension Sep 17 14:22:35 +02:00 api13 [info] api: Sep 17 14:22:35 +02:00 api13 [info] api: RPython traceback: Sep 17 14:22:35 +02:00 api13 [info] api: File "rpython_jit_metainterp_warmspot.c", line 1477, in ll_portal_runner__Unsigned_Bool_pypy_interpreter Sep 17 14:22:35 +02:00 api13 [info] api: File "pypy_module_pypyjit_interp_jit.c", line 227, in portal_4 Sep 17 14:22:35 +02:00 api13 [info] api: File "pypy_interpreter_pyopcode.c", line 3068, in handle_bytecode__AccessDirect_None Sep 17 14:22:35 +02:00 api13 [info] api: File "pypy_module_pypyjit_interp_jit.c", line 111, in jump_absolute__AccessDirect_None Sep 17 14:22:35 +02:00 api13 [info] api: File "rpython_jit_metainterp_warmspot.c", line 3630, in crash_in_jit_2 ---------- messages: 6172 nosy: balboah, pypy-issue priority: critical release: 2.1 status: unread title: Fatal error calling PyEval_SaveThread ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 17 14:32:26 2013 From: tracker at bugs.pypy.org (Johnny Boy) Date: Tue, 17 Sep 2013 12:32:26 +0000 Subject: [pypy-issue] [issue1604] ** buffer overflow detected ***: /var/www/api/pypy/bin/pypy terminated In-Reply-To: <1378992853.13.0.610639275293.issue1604@bugs.pypy.org> Message-ID: <1379421146.59.0.0815291968341.issue1604@bugs.pypy.org> Johnny Boy added the comment: Sorry, the last part is: -c $PYTHONPATH/api/gunicorn.py run:app Where the gunicorn.py config says: syslog = True syslog_facility = "daemon" syslog_prefix = "duego-api" ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 17 14:33:40 2013 From: tracker at bugs.pypy.org (Johnny Boy) Date: Tue, 17 Sep 2013 12:33:40 +0000 Subject: [pypy-issue] [issue1604] ** buffer overflow detected ***: /var/www/api/pypy/bin/pypy terminated In-Reply-To: <1378992853.13.0.610639275293.issue1604@bugs.pypy.org> Message-ID: <1379421220.37.0.74469825726.issue1604@bugs.pypy.org> Johnny Boy added the comment: I have since decided to not use eventlet and instead try gevent. Seems to work okay so far ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 17 14:36:05 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Tue, 17 Sep 2013 12:36:05 +0000 Subject: [pypy-issue] [issue1603] Exception: 'no_release_gil' function can release the GIL In-Reply-To: <1378945702.82.0.303632350502.issue1603@bugs.pypy.org> Message-ID: <1379421365.07.0.0407525822948.issue1603@bugs.pypy.org> Armin Rigo added the comment: traceback2.txt contains a complete traceback with, at the bottom, the function that should not release the GIL (here Logger.log_loop), with every function before being potentially called (so actually in the reverse order as a regular Python traceback), ending at the top at a function that actually releases the GIL (here ccall_fstat64_..). In this case the bogus part is near the end: get_printable_location() calls PyCode.get_repr, which on "default" does not call anything else, but which in the py3k branch calls space.fsdecode_w() which can indirectly call anything at all. You need to fix this get_printable_location(). (Note that it's only used for debugging anyway.) ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 17 16:12:39 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Tue, 17 Sep 2013 14:12:39 +0000 Subject: [pypy-issue] [issue1604] ** buffer overflow detected ***: /var/www/api/pypy/bin/pypy terminated In-Reply-To: <1378992853.13.0.610639275293.issue1604@bugs.pypy.org> Message-ID: <1379427159.81.0.0992265442943.issue1604@bugs.pypy.org> Armin Rigo added the comment: ImportError: No module named run Could you give a *checked* step-by-step example of what we need to do? You can also include a .tar.gz file if necessary. I would love to be able to reproduce this crash, even if you decided to use something else already. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 17 16:14:39 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Tue, 17 Sep 2013 14:14:39 +0000 Subject: [pypy-issue] [issue1607] Fatal error calling PyEval_SaveThread In-Reply-To: <1379420782.98.0.478846388508.issue1607@bugs.pypy.org> Message-ID: <1379427279.44.0.727818859343.issue1607@bugs.pypy.org> Armin Rigo added the comment: Either you give us a way to reproduce the problem, or I'm closing the bug report as "Invalid". ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 18 00:30:53 2013 From: tracker at bugs.pypy.org (Philip Jenvey) Date: Tue, 17 Sep 2013 22:30:53 +0000 Subject: [pypy-issue] [issue1600] py3k: merge over uuid & argparse changes from default In-Reply-To: <1378934472.33.0.785041988609.issue1600@bugs.pypy.org> Message-ID: <1379457053.61.0.429463644865.issue1600@bugs.pypy.org> Philip Jenvey added the comment: fixed in f2b132476063 & e2d622c67269 ---------- status: unread -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 18 01:03:14 2013 From: tracker at bugs.pypy.org (orf) Date: Tue, 17 Sep 2013 23:03:14 +0000 Subject: [pypy-issue] [issue1608] Memory leak when accessing a dictionary with an non-existent key In-Reply-To: <1379458994.59.0.703877819873.issue1608@bugs.pypy.org> Message-ID: <1379458994.59.0.703877819873.issue1608@bugs.pypy.org> New submission from orf : Running the attached code using 2.1 on Windows will cause a MemoryError. It creates a dictionary containing 10,000,000 unicode keys and attempts to access the dictionary using both a valid and an invalid key Upon accessing the dictionary with an invalid key the program terminates with a MemoryError. ---------- files: pypy_bug.py messages: 6179 nosy: orf, pypy-issue priority: bug release: 2.1 status: unread title: Memory leak when accessing a dictionary with an non-existent key ________________________________________ PyPy bug tracker ________________________________________ -------------- next part -------------- import random, string big_dict = {"".join([random.choice(string.printable) for i in xrange(40)]): random.randint(0,10000) for _ in xrange(10000000)} valid_key = big_dict.keys()[0] print "Valid key: %s" % big_dict[valid_key] print "Invalid key: %s" % big_dict["test"] From tracker at bugs.pypy.org Wed Sep 18 01:10:12 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Tue, 17 Sep 2013 23:10:12 +0000 Subject: [pypy-issue] [issue1609] SIGSEGV at startup if compiled with ICC In-Reply-To: <1379459412.97.0.141999922918.issue1609@bugs.pypy.org> Message-ID: <1379459412.97.0.141999922918.issue1609@bugs.pypy.org> New submission from Greg Czajkowski : How can I rebuild pypy with debug symbols? I'm getting a crash right at startup if it's compiled with ICC Program received signal SIGSEGV, Segmentation fault. 0x00000000013471cc in pypy_g_walk_to_parent_frame () (gdb) bt #0 0x00000000013471cc in pypy_g_walk_to_parent_frame () #1 0x0000000001346f51 in pypy_g__asm_callback () #2 0x00000000015a5b3d in pypy_asm_stackwalk () #3 0x0000000001340889 in pypy_g_MiniMarkGC_minor_collection () #4 0x000000000133df51 in pypy_g_MiniMarkGC_setup () #5 0x0000000001347ed1 in pypy_g_frameworkgc_setup () #6 0x0000000000412c16 in RPython_StartupCode () #7 0x000000000159eec8 in main () ---------- messages: 6180 nosy: gcflymoto, pypy-issue priority: bug release: 2.1 status: unread title: SIGSEGV at startup if compiled with ICC ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 18 01:26:49 2013 From: tracker at bugs.pypy.org (Philip Jenvey) Date: Tue, 17 Sep 2013 23:26:49 +0000 Subject: [pypy-issue] [issue1603] Exception: 'no_release_gil' function can release the GIL In-Reply-To: <1378945702.82.0.303632350502.issue1603@bugs.pypy.org> Message-ID: <1379460409.37.0.529636639915.issue1603@bugs.pypy.org> Philip Jenvey added the comment: thanks Armin fixed in 464c7c15c57c, thanks for the bug report ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 18 14:46:46 2013 From: tracker at bugs.pypy.org (Johnny Boy) Date: Wed, 18 Sep 2013 12:46:46 +0000 Subject: [pypy-issue] [issue1607] Fatal error calling PyEval_SaveThread In-Reply-To: <1379420782.98.0.478846388508.issue1607@bugs.pypy.org> Message-ID: <1379508406.83.0.372653003396.issue1607@bugs.pypy.org> Johnny Boy added the comment: I don't know how to reproduce the problem so I guess you'll have to close it ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 18 19:18:11 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Wed, 18 Sep 2013 17:18:11 +0000 Subject: [pypy-issue] [issue1603] Exception: 'no_release_gil' function can release the GIL In-Reply-To: <1378945702.82.0.303632350502.issue1603@bugs.pypy.org> Message-ID: <1379524691.52.0.823692661891.issue1603@bugs.pypy.org> Greg Czajkowski added the comment: Thanks. Got passed that error. Ill post a new ticket for the next one. ---------- status: resolved -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 18 19:21:18 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Wed, 18 Sep 2013 17:21:18 +0000 Subject: [pypy-issue] [issue1610] undefined reference to `SSL_set_tlsext_host_name' In-Reply-To: <1379524878.43.0.499479578156.issue1610@bugs.pypy.org> Message-ID: <1379524878.43.0.499479578156.issue1610@bugs.pypy.org> New submission from Greg Czajkowski : After resolving issue1603 py3k build fails with [translation:ERROR] /tmp/ccBdWvKg.o: In function `pypy_g_ccall_SSL_set_tlsext_host_name__SSLPtr_arrayPtr_': [translation:ERROR] implement_16.c:(.text+0x1b57c): undefined reference to `SSL_set_tlsext_host_name' is there a way to specify openssl path to the build? Here is my current way of building env LD_LIBRARY_PATH=/path/libffi.gcc/lib64 CFLAGS="-I /path/libffi.gcc/lib/libffi-3.0.13/include" LDFLAGS="-L/path/libffi.gcc/lib64" /usr/pkgs/python/2.7.2/bin/python ../../rpython/bin/rpython -- opt=jit --batch --cc=/usr/pkgs/gcc/4.8.1/bin/gcc targetpypystandalone Context: branch py3k, machine is SUSE10 I'll attempt to set LDFLAGS and report back ---------- messages: 6184 nosy: gcflymoto, pypy-issue priority: bug release: 2.1 status: unread title: undefined reference to `SSL_set_tlsext_host_name' ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 18 19:34:06 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Wed, 18 Sep 2013 17:34:06 +0000 Subject: [pypy-issue] [issue1610] undefined reference to `SSL_set_tlsext_host_name' In-Reply-To: <1379524878.43.0.499479578156.issue1610@bugs.pypy.org> Message-ID: <1379525646.09.0.126234466786.issue1610@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: Your version of OpenSSL is probably older than 1.0.0. PyPy should protect this call with a "if HAS_SNI" tag:easy ---------- nosy: +amaury status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 19 00:06:21 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Wed, 18 Sep 2013 22:06:21 +0000 Subject: [pypy-issue] [issue1610] undefined reference to `SSL_set_tlsext_host_name' In-Reply-To: <1379524878.43.0.499479578156.issue1610@bugs.pypy.org> Message-ID: <1379541981.87.0.924402603985.issue1610@bugs.pypy.org> Greg Czajkowski added the comment: Thanks for the solution. It took both a proper config of -I and -L to point to a more recent openssl to convince pypy to build pypy3 .. env LD_LIBRARY_PATH=/path/libffi.gcc/lib64:/usr/intel/pkgs/openssl/1.0.1c/lib64 CFLAGS="-I /path/libffi.gcc/lib/libffi-3.0.13/include -I /usr/pkgs/openssl/1.0.1c/include -I /usr/pkgs/openssl/1.0.1c/openssl" LDFLAGS="-L/path/libffi.gcc/lib64 - L/usr/pkgs/openssl/1.0.1c/lib64" /usr/pkgs/python/2.7.2/bin/python ../../rpython/bin/rpython --opt=jit --batch --cc=/usr/pkgs/gcc/4.8.1/bin/gcc targetpypystandalone.py ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 19 00:21:32 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Wed, 18 Sep 2013 22:21:32 +0000 Subject: [pypy-issue] [issue1611] pypy3: setupterm: could not find terminal In-Reply-To: <1379542892.61.0.890505869939.issue1611@bugs.pypy.org> Message-ID: <1379542892.61.0.890505869939.issue1611@bugs.pypy.org> New submission from Greg Czajkowski : After building pypy3 solving issue1610 issue1603 and issue1601 pypy-c cannot start and raises the attached traceback ... _minimal_curses.error: setupterm: could not find terminal Context: py3k branch built on linux SUSE10 Compile Command env LD_LIBRARY_PATH=/path/libffi.gcc/lib64:/usr/pkgs/openssl/1.0.1c/lib64 CFLAGS="-I /path/libffi.gcc/lib/libffi-3.0.13/include -I /usr/pkgs/openssl/1.0.1c/include - I /usr/pkgs/openssl/1.0.1c/openssl" LDFLAGS="-L/path/libffi.gcc/lib64 - L/usr/pkgs/openssl/1.0.1c/lib64" /usr/pkgs/python/2.7.2/bin/python ../../rpython/bin/rpython --opt=jit --batch --cc=/usr/pkgs/gcc/4.8.1/bin/gcc targetpypystandalone.py ---------- messages: 6187 nosy: gcflymoto, pypy-issue priority: bug status: unread title: pypy3: setupterm: could not find terminal ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 19 00:26:21 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Wed, 18 Sep 2013 22:26:21 +0000 Subject: [pypy-issue] [issue1610] undefined reference to `SSL_set_tlsext_host_name' In-Reply-To: <1379524878.43.0.499479578156.issue1610@bugs.pypy.org> Message-ID: <1379543181.28.0.0907243293914.issue1610@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: reopening: we should modify our _ssl module to accept older OpenSSL versions ---------- status: resolved -> in-progress ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 19 16:22:40 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Thu, 19 Sep 2013 14:22:40 +0000 Subject: [pypy-issue] [issue1609] SIGSEGV at startup if compiled with ICC In-Reply-To: <1379459412.97.0.141999922918.issue1609@bugs.pypy.org> Message-ID: <1379600560.53.0.802963587258.issue1609@bugs.pypy.org> Armin Rigo added the comment: It's expected: "asmgcc" is only really supported with gcc. You need to retranslate with "--gcrootfinder=shadowstack". (To get debug symbols, the easiest is to transalate, then cd /tmp/usession-xxx/testing_1 (details printed in the last page of translation), and type "make lldebug".) ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Thu Sep 19 19:55:54 2013 From: tracker at bugs.pypy.org (Fijal) Date: Thu, 19 Sep 2013 17:55:54 +0000 Subject: [pypy-issue] [issue1609] SIGSEGV at startup if compiled with ICC In-Reply-To: <1379459412.97.0.141999922918.issue1609@bugs.pypy.org> Message-ID: <1379613354.06.0.672714138636.issue1609@bugs.pypy.org> Fijal added the comment: Maybe we should really disable auto-using asmgcc when we're not on gcc? ---------- nosy: +fijal ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 20 02:10:49 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Fri, 20 Sep 2013 00:10:49 +0000 Subject: [pypy-issue] [issue1609] SIGSEGV at startup if compiled with ICC In-Reply-To: <1379459412.97.0.141999922918.issue1609@bugs.pypy.org> Message-ID: <1379635849.48.0.576589332667.issue1609@bugs.pypy.org> Greg Czajkowski added the comment: --gcrootfinder=shadowstack worked great. Thanks ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 20 11:23:19 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 20 Sep 2013 09:23:19 +0000 Subject: [pypy-issue] [issue1608] Memory leak when accessing a dictionary with an non-existent key In-Reply-To: <1379458994.59.0.703877819873.issue1608@bugs.pypy.org> Message-ID: <1379668999.25.0.867968552863.issue1608@bugs.pypy.org> Armin Rigo added the comment: Just checking: the big dict contains string keys, not unicode keys. Is that right? ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 20 11:38:28 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 20 Sep 2013 09:38:28 +0000 Subject: [pypy-issue] [issue1608] Memory leak when accessing a dictionary with an non-existent key In-Reply-To: <1379458994.59.0.703877819873.issue1608@bugs.pypy.org> Message-ID: <1379669908.31.0.349848173531.issue1608@bugs.pypy.org> Armin Rigo added the comment: Cannot reproduce: on Win32, running PyPy 2.1, it works for me, consuming almost exactly 1GB of RAM and then finishing successfully (with "KeyError"). It also works on Linux (32-bit, no swapping with only 2GB of RAM). ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 20 11:45:14 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 20 Sep 2013 09:45:14 +0000 Subject: [pypy-issue] [issue1607] Fatal error calling PyEval_SaveThread In-Reply-To: <1379420782.98.0.478846388508.issue1607@bugs.pypy.org> Message-ID: <1379670314.05.0.0131070435287.issue1607@bugs.pypy.org> Armin Rigo added the comment: What I mean is that we are fine with getting bug reports, but you need to collaborate with us a little bit more, otherwise the bug reports are completely useless to us. In this case, it would already be helpful if you could come up with a recipe like this: ``on Linux (version X.Y.Z), do "pip install x y z", then repeatedly run this attached code, and you'll get sometimes a crash.'' If for some reason you cannot disclose the code in question, then indeed I will just close this. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 20 11:51:54 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 20 Sep 2013 09:51:54 +0000 Subject: [pypy-issue] [issue1610] undefined reference to `SSL_set_tlsext_host_name' In-Reply-To: <1379524878.43.0.499479578156.issue1610@bugs.pypy.org> Message-ID: <1379670714.14.0.63662561235.issue1610@bugs.pypy.org> Armin Rigo added the comment: Amaury: as far as I can tell, it would avoid tons of troubles if we moved the "_ssl" module to be pure Python and cffi-based. It would not be any easier to get it working, but at least for people that don't care about _ssl it avoids all these troubles. I would expect this is the vast majority of people, given that people that *really* care use something different like PyOpenSSL anyway. ---------- nosy: +arigo ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 20 11:54:25 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Fri, 20 Sep 2013 09:54:25 +0000 Subject: [pypy-issue] [issue1609] SIGSEGV at startup if compiled with ICC In-Reply-To: <1379459412.97.0.141999922918.issue1609@bugs.pypy.org> Message-ID: <1379670865.6.0.699262215985.issue1609@bugs.pypy.org> Armin Rigo added the comment: fijal: something like running "$CC --version", and if it doesn't answer "gcc" we disable it? Additionally, if it answers "gcc X.Y.Z" with some unsupported number X.Y.Z we can put big warnings... ---------- status: resolved -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 20 19:20:47 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Fri, 20 Sep 2013 17:20:47 +0000 Subject: [pypy-issue] [issue1610] undefined reference to `SSL_set_tlsext_host_name' In-Reply-To: <1379524878.43.0.499479578156.issue1610@bugs.pypy.org> Message-ID: <1379697647.35.0.223749040072.issue1610@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: Yes, good idea. The error would still show, but only with "import ssl", and workaround would be immediate. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 21 02:51:34 2013 From: tracker at bugs.pypy.org (orf) Date: Sat, 21 Sep 2013 00:51:34 +0000 Subject: [pypy-issue] [issue1608] Memory leak when accessing a dictionary with an non-existent key In-Reply-To: <1379458994.59.0.703877819873.issue1608@bugs.pypy.org> Message-ID: <1379724694.37.0.462192384019.issue1608@bugs.pypy.org> orf added the comment: Weird, I tried the attached code on another (older) Windows machine and it executed fine. I changed all the keys to be unicode and it failed with a string lookup (attached). Could you try running this code instead? ________________________________________ PyPy bug tracker ________________________________________ -------------- next part -------------- import random, string big_dict = {u"".join([random.choice(string.printable) for i in xrange(40)]): random.randint(0,10000) for _ in xrange(10000000)} valid_key = big_dict.keys()[0] print "Valid key: %s" % big_dict[valid_key] print "Invalid key: %s" % big_dict["test"] From tracker at bugs.pypy.org Sat Sep 21 10:44:25 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 21 Sep 2013 08:44:25 +0000 Subject: [pypy-issue] [issue1608] Memory leak when accessing a dictionary with an non-existent key In-Reply-To: <1379458994.59.0.703877819873.issue1608@bugs.pypy.org> Message-ID: <1379753065.65.0.427366065475.issue1608@bugs.pypy.org> Armin Rigo added the comment: pypy_bug_ukey.py shows an example where it is expected to get MemoryError: you are building a so-called "unicode strategy" dictionary, which means a dict that is specialized to store unicode objects only as keys. But then when you try to look up an object of a different type --- like string --- it will fall back the whole dictionary to a general-typed dictionary. In this case we run out of memory trying to make the general-typed copy. This is done because the alternative is harder to implement: that would be trying to search the internal unicode-only dictionary for a plain string object. The drawback is mainly that it is surprizing to get a MemoryError on a plain lookup, but otherwise the drawback is generally relatively minor, except in special cases like yours. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 22 11:42:08 2013 From: tracker at bugs.pypy.org (Graham Dumpleton) Date: Sun, 22 Sep 2013 09:42:08 +0000 Subject: [pypy-issue] [issue1612] operator.__index__() is missing. In-Reply-To: <1379842928.66.0.180197020669.issue1612@bugs.pypy.org> Message-ID: <1379842928.66.0.180197020669.issue1612@bugs.pypy.org> New submission from Graham Dumpleton : CPython has both the following in the operator module: operator.index() operator.__index__() This is documented at: http://docs.python.org/2/library/operator.html#operator.index The pypy version of the operator module is missing __index__(). IOW, has 'index' here: https://bitbucket.org/pypy/pypy/src/162d46b91e963450e3e9461b37c14860e6c49b32/pypy/ module/operator/__init__.py?at=default#cl-29 but missing '__index__' in mapping at: https://bitbucket.org/pypy/pypy/src/162d46b91e963450e3e9461b37c14860e6c49b32/pypy/ module/operator/__init__.py?at=default#cl-46 ---------- messages: 6200 nosy: GrahamDumpleton, pypy-issue priority: bug status: unread title: operator.__index__() is missing. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 22 15:34:16 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sun, 22 Sep 2013 13:34:16 +0000 Subject: [pypy-issue] [issue1612] operator.__index__() is missing. In-Reply-To: <1379842928.66.0.180197020669.issue1612@bugs.pypy.org> Message-ID: <1379856856.66.0.946411925467.issue1612@bugs.pypy.org> Armin Rigo added the comment: Thanks! Added in a82f83c4d0a0. ---------- nosy: +arigo status: unread -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 22 16:44:03 2013 From: tracker at bugs.pypy.org (orf) Date: Sun, 22 Sep 2013 14:44:03 +0000 Subject: [pypy-issue] [issue1608] Memory leak when accessing a dictionary with an non-existent key In-Reply-To: <1379458994.59.0.703877819873.issue1608@bugs.pypy.org> Message-ID: <1379861043.18.0.744216356183.issue1608@bugs.pypy.org> orf added the comment: That makes sense, would it be possible to add a more descriptive error message? A MemoryError when accessing a key is surprising, would adding a more reasonable message be hard? ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 23 15:15:00 2013 From: tracker at bugs.pypy.org (Pierre LM) Date: Mon, 23 Sep 2013 13:15:00 +0000 Subject: [pypy-issue] [issue1613] Utf-8 encoding problem with Powershell on Windows In-Reply-To: <1379942100.49.0.246912601269.issue1613@bugs.pypy.org> Message-ID: <1379942100.49.0.246912601269.issue1613@bugs.pypy.org> New submission from Pierre LM : Hi, I have tried the official binaries of pypy3 2.1b1 on Windows 7 64bits. There is a problem with the utf-8 encoding (code page 65001) in Powershell 2.0 and cmd.exe. Please find herebelow a copy of the terminal: PS C:\temp\pypy3-2.1-beta1-win32> chcp 1252 Aktive Codepage: 1252. PS C:\temp\pypy3-2.1-beta1-win32> .\pypy.exe Python 3.2.3 (d63636b30cc0, Jul 30 2013, 07:02:44) [PyPy 2.1.0-beta1 with MSC v.1500 32 bit] on win32 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``"3 + 3 = 8" - Anto in the JIT talk'' >>>> exit() PS C:\temp\pypy3-2.1-beta1-win32> chcp 65001 Aktive Codepage: 65001. PS C:\temp\pypy3-2.1-beta1-win32> .\pypy.exe debug: OperationError: debug: operror-type: LookupError debug: operror-value: unknown encoding: cp65001 debug: OperationError: debug: operror-type: AttributeError debug: operror-value: 'module' object has no attribute 'stderr' PS C:\temp\pypy3-2.1-beta1-win32> ---------- messages: 6203 nosy: plm, pypy-issue priority: bug release: 2.1 status: unread title: Utf-8 encoding problem with Powershell on Windows ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 23 16:33:37 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Mon, 23 Sep 2013 14:33:37 +0000 Subject: [pypy-issue] [issue1610] undefined reference to `SSL_set_tlsext_host_name' In-Reply-To: <1379524878.43.0.499479578156.issue1610@bugs.pypy.org> Message-ID: <1379946817.74.0.230111273394.issue1610@bugs.pypy.org> Armin Rigo added the comment: Ah, but the "_hashlib" module is also concerned. I fear it wouldn't really solve anything then... ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 23 17:24:36 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Mon, 23 Sep 2013 15:24:36 +0000 Subject: [pypy-issue] [issue1613] Utf-8 encoding problem with Powershell on Windows In-Reply-To: <1379942100.49.0.246912601269.issue1613@bugs.pypy.org> Message-ID: <1379949876.34.0.0942116380836.issue1613@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: cp65001 was added in Python 3.3, see http://bugs.python.org/issue13216 So far, pypy3 only implements Python 3.2.3. I checked that the 3.3 test suite has substantial unit tests for the cp65001 encoding, so I'm closing this issue. We will implement it later, when pypy3 is upgraded to 3.3. ---------- nosy: +amaury status: unread -> wontfix ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 23 17:29:06 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Mon, 23 Sep 2013 15:29:06 +0000 Subject: [pypy-issue] [issue1610] undefined reference to `SSL_set_tlsext_host_name' In-Reply-To: <1379524878.43.0.499479578156.issue1610@bugs.pypy.org> Message-ID: <1379950146.98.0.221132379544.issue1610@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: ...unless we remove completely SSL_set_tlsext_host_name from rlib/ropenssl.py ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 23 17:42:30 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Mon, 23 Sep 2013 15:42:30 +0000 Subject: [pypy-issue] [issue1610] undefined reference to `SSL_set_tlsext_host_name' In-Reply-To: <1379524878.43.0.499479578156.issue1610@bugs.pypy.org> Message-ID: <1379950950.47.0.0925647975946.issue1610@bugs.pypy.org> Armin Rigo added the comment: I'm talking about the more common problem of locating the right version of openssl here, which is absurdly messy. I'm rather sure I don't want twice as much "fun" as we already have, with openssl linked both statically and dynamically. Maybe it makes sense to have _hashlib also written at app-level as a CFFI module? And maybe falling back to the non-openssl-based version transparently? It looks tempting but it would have a silent impact on performance depending on the installation :-( ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 24 14:42:16 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Tue, 24 Sep 2013 12:42:16 +0000 Subject: [pypy-issue] [issue1608] Memory leak when accessing a dictionary with an non-existent key In-Reply-To: <1379458994.59.0.703877819873.issue1608@bugs.pypy.org> Message-ID: <1380026536.86.0.171046137943.issue1608@bugs.pypy.org> Armin Rigo added the comment: It's probably not hard to have the final error show up as "MemoryError: cannot convert dictionary from UnicodeDictStrategy to ObjectDictStrategy". Would such a message be helpful in your opinion? Should we also try to have a similar message on list strategies? These are two places I can think of where CPython never needs a lot of memory to complete, but where PyPy might. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 24 20:19:49 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Tue, 24 Sep 2013 18:19:49 +0000 Subject: [pypy-issue] [issue1611] pypy3: setupterm: could not find terminal In-Reply-To: <1379542892.61.0.890505869939.issue1611@bugs.pypy.org> Message-ID: <1380046789.2.0.896082419897.issue1611@bugs.pypy.org> Greg Czajkowski added the comment: Added traceback ---------- status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ -------------- next part -------------- > pypy.3.2-gcc-c Python 3.2.3 (?, Sep 18 2013, 23:13:49) [PyPy 2.2.0-alpha0] on linux2 Type "help", "copyright", "credits" or "license" for more information. Traceback (most recent call last): File "/etc/pythonstart", line 20, in readline.read_history_file(historyPath) File "/path/pypy/lib_pypy/pyrepl/readline.py", line 260, in read_history_file history = self.get_reader().history File "/path/pypy/lib_pypy/pyrepl/readline.py", line 192, in get_reader console = UnixConsole(self.f_in, self.f_out, encoding=ENCODING) File "/path/pypy/lib_pypy/pyrepl/unix_console.py", line 105, in __init__ curses.setupterm(term, self.output_fd) _minimal_curses.error: setupterm: could not find terminal And now for something completely different: ``it is the expected behavior, except when you don't expect it'' Traceback (most recent call last): File "/path/pypy/lib_pypy/_pypy_interact.py", line 36, in interactive_console raise ImportError ImportError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/path/pypy/lib_pypy/pyrepl/readline.py", line 199, in raw_input reader = self.get_reader() File "/path/pypy/lib_pypy/pyrepl/readline.py", line 192, in get_reader console = UnixConsole(self.f_in, self.f_out, encoding=ENCODING) File "/path/pypy/lib_pypy/pyrepl/unix_console.py", line 105, in __init__ curses.setupterm(term, self.output_fd) _minimal_curses.error: setupterm: could not find terminal During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/path/pypy/lib_pypy/_pypy_interact.py", line 39, in interactive_console run_simple_interactive_console(mainmodule) File "/path/pypy/lib_pypy/_pypy_interact.py", line 62, in run_simple_interactive_console line = input(prompt) File "/path/pypy/lib_pypy/pyrepl/readline.py", line 201, in raw_input return _old_raw_input(prompt) File "/path/pypy/lib_pypy/pyrepl/readline.py", line 425, in _old_raw_input return raw_input(prompt) NameError: global name 'raw_input' is not defined From tracker at bugs.pypy.org Tue Sep 24 21:06:25 2013 From: tracker at bugs.pypy.org (benoitc) Date: Tue, 24 Sep 2013 19:06:25 +0000 Subject: [pypy-issue] [issue1614] creating a continulet is slow In-Reply-To: <1380049585.68.0.83459615215.issue1614@bugs.pypy.org> Message-ID: <1380049585.68.0.83459615215.issue1614@bugs.pypy.org> New submission from benoitc : I am testing the creation of a continulet vs a is base on the fiber (https://github.com/saghul/python-fibers) which reuse the stacklet code from pypy and creating a bunch of continulet is a lot slower: $ time python ../test_create_fibers.py real 0m0.476s user 0m0.430s sys 0m0.042s $ time python ../test_create_continulets.py real 6m46.469s user 0m2.992s sys 6m41.558s ---------- files: test_create_continulets.py messages: 6210 nosy: benoitc, pypy-issue priority: performance bug status: unread title: creating a continulet is slow ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 24 21:29:03 2013 From: tracker at bugs.pypy.org (benoitc) Date: Tue, 24 Sep 2013 19:29:03 +0000 Subject: [pypy-issue] [issue1614] creating a continulet is slow In-Reply-To: <1380049585.68.0.83459615215.issue1614@bugs.pypy.org> Message-ID: <1380050943.29.0.863974436218.issue1614@bugs.pypy.org> benoitc added the comment: The difference come from the way the frame is created. Fiber apparently create it the first time it's switched while continulet are created immediately. Not sure if it's an issue but it considerably change the performances. ---------- status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Tue Sep 24 23:06:29 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Tue, 24 Sep 2013 21:06:29 +0000 Subject: [pypy-issue] [issue1614] creating a continulet is slow In-Reply-To: <1380049585.68.0.83459615215.issue1614@bugs.pypy.org> Message-ID: <1380056789.6.0.720673245156.issue1614@bugs.pypy.org> Armin Rigo added the comment: It means the benchmark is mostly useless. Try to benchmark the time it takes to create *and switch to* a fiber vs a continulet. ---------- nosy: +arigo ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 25 00:04:01 2013 From: tracker at bugs.pypy.org (benoitc) Date: Tue, 24 Sep 2013 22:04:01 +0000 Subject: [pypy-issue] [issue1614] creating a continulet is slow In-Reply-To: <1380049585.68.0.83459615215.issue1614@bugs.pypy.org> Message-ID: <1380060241.33.0.777337271528.issue1614@bugs.pypy.org> benoitc added the comment: The test shows that continulets are created/bound at the creation, which slow down the insertion in the queue. This is all what this test means. When it's about switching the time is quite equivalent. I had to lazily create the continulets before switching to them to fix that. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 25 07:28:51 2013 From: tracker at bugs.pypy.org (kostia.lopuhin) Date: Wed, 25 Sep 2013 05:28:51 +0000 Subject: [pypy-issue] [issue1599] quadratic time in list.extend(sometuple) In-Reply-To: <1378919443.8.0.0332374191379.issue1599@bugs.pypy.org> Message-ID: <1380086931.77.0.275618504208.issue1599@bugs.pypy.org> kostia.lopuhin added the comment: A similar (and maybe even more common in real code?) problem just bit us with extending list from an array - see attached program that runs hunderds times slower under PyPy - just doing list.extend(some_int_array) ---------- nosy: +kostia.lopuhin ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 25 11:37:53 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Wed, 25 Sep 2013 09:37:53 +0000 Subject: [pypy-issue] [issue1599] quadratic time in list.extend(sometuple) In-Reply-To: <1378919443.8.0.0332374191379.issue1599@bugs.pypy.org> Message-ID: <1380101873.01.0.548546486663.issue1599@bugs.pypy.org> Armin Rigo added the comment: Found the reason: the problem is indeed not the 2nd call to _resize_list() in _extend_from_iterable(), which is never called in this example. The problem is the 1st call. It resizes by growing the list to *exactly* the specified size, instead of overallocating a bit. See the 'overallocate' argument to _ll_list_resize_hint_really(). We need to figure out if it ever makes sense to pass False here, or if we shouldn't just always overallocate. ---------- nosy: +arigo ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 25 11:44:31 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Wed, 25 Sep 2013 09:44:31 +0000 Subject: [pypy-issue] [issue1614] creating a continulet is slow In-Reply-To: <1380049585.68.0.83459615215.issue1614@bugs.pypy.org> Message-ID: <1380102271.38.0.242253964764.issue1614@bugs.pypy.org> Armin Rigo added the comment: It's too late to make continulets lazy. The problem is that it's a behavior that we cannot change: it changes the place in the stack which is where the continulet will start. It would break e.g. the example listed in https://pypy.readthedocs.org/en/latest/stackless.html#recursion-depth-limit . I'm unsure I understand why you need to create a large number of continulets without switching to them, but I'm glad you found a workaround. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 25 13:36:19 2013 From: tracker at bugs.pypy.org (benoitc) Date: Wed, 25 Sep 2013 11:36:19 +0000 Subject: [pypy-issue] [issue1614] creating a continulet is slow In-Reply-To: <1380049585.68.0.83459615215.issue1614@bugs.pypy.org> Message-ID: <1380108979.83.0.145064895741.issue1614@bugs.pypy.org> benoitc added the comment: fair enough :) In my case I create the coroutines that I put in a scheduler. So depending on the code some are creating a coroutine on which they will send some values via the channels (similar to Go or stackless). So they are all queued first in the run queue The relevant issue in my project is: https://github.com/benoitc/offset/issues/8 ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Wed Sep 25 17:53:25 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Wed, 25 Sep 2013 15:53:25 +0000 Subject: [pypy-issue] [issue1599] quadratic time in list.extend(sometuple) In-Reply-To: <1378919443.8.0.0332374191379.issue1599@bugs.pypy.org> Message-ID: <1380124405.97.0.477495684759.issue1599@bugs.pypy.org> Armin Rigo added the comment: Should be fixed in 69b168abce65. ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 27 20:46:00 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Fri, 27 Sep 2013 18:46:00 +0000 Subject: [pypy-issue] [issue1611] pypy3: cannot start crashes with terminal issues In-Reply-To: <1379542892.61.0.890505869939.issue1611@bugs.pypy.org> Message-ID: <1380307560.71.0.149267152974.issue1611@bugs.pypy.org> Greg Czajkowski added the comment: Does py3k HEAD work for anybody else? I'm seeing the attached crash ---------- title: pypy3: setupterm: could not find terminal -> pypy3: cannot start crashes with terminal issues ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 27 21:26:01 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Fri, 27 Sep 2013 19:26:01 +0000 Subject: [pypy-issue] [issue1611] pypy3: cannot start crashes with terminal issues In-Reply-To: <1379542892.61.0.890505869939.issue1611@bugs.pypy.org> Message-ID: <1380309961.9.0.809571540373.issue1611@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: I get the same error when I run: TERM=something ./pypy-c Does it change something if you reset the TERM env var? ---------- nosy: +amaury ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 27 21:57:48 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Fri, 27 Sep 2013 19:57:48 +0000 Subject: [pypy-issue] [issue1611] pypy3: cannot start crashes with terminal issues In-Reply-To: <1379542892.61.0.890505869939.issue1611@bugs.pypy.org> Message-ID: <1380311868.34.0.955766298688.issue1611@bugs.pypy.org> Greg Czajkowski added the comment: It's slightly different "could not find terminfo database" as opposed to "could not find terminal" > pypy.3.2-gcc-c Python 3.2.3 (?, Sep 18 2013, 23:13:49) [PyPy 2.2.0-alpha0] on linux2 Type "help", "copyright", "credits" or "license" for more information. Traceback (most recent call last): File "/etc/pythonstart", line 20, in readline.read_history_file(historyPath) File "/path/pypy/lib_pypy/pyrepl/readline.py", line 260, in read_history_file history = self.get_reader().history File "/path/pypy/lib_pypy/pyrepl/readline.py", line 192, in get_reader console = UnixConsole(self.f_in, self.f_out, encoding=ENCODING) File "/path/pypy/lib_pypy/pyrepl/unix_console.py", line 105, in __init__ curses.setupterm(term, self.output_fd) _minimal_curses.error: setupterm: could not find terminfo database ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Fri Sep 27 22:05:31 2013 From: tracker at bugs.pypy.org (Philip Jenvey) Date: Fri, 27 Sep 2013 20:05:31 +0000 Subject: [pypy-issue] [issue1611] pypy3: cannot start crashes with terminal issues In-Reply-To: <1379542892.61.0.890505869939.issue1611@bugs.pypy.org> Message-ID: <1380312331.66.0.494537884779.issue1611@bugs.pypy.org> Philip Jenvey added the comment: The main issue here is we were referencing raw_input instead of input (in probably a fallback version of raw_input which is used when the terminfo setup fails) I belive I've fixed it ee7dd757b1df: the terminfo setup failure becomes ignored as it's supposed to ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 28 03:11:52 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Sat, 28 Sep 2013 01:11:52 +0000 Subject: [pypy-issue] [issue1611] pypy3: cannot start crashes with terminal issues In-Reply-To: <1379542892.61.0.890505869939.issue1611@bugs.pypy.org> Message-ID: <1380330712.39.0.789986068998.issue1611@bugs.pypy.org> Greg Czajkowski added the comment: It comes up now, with the terminal error being ignored.. > pypy.3.2-gcc-c Python 3.2.3 (?, Sep 27 2013, 23:47:12) [PyPy 2.2.0-alpha0] on linux2 Type "help", "copyright", "credits" or "license" for more information. Traceback (most recent call last): File "/etc/pythonstart", line 20, in readline.read_history_file(historyPath) File "/path/pypy/lib_pypy/pyrepl/readline.py", line 260, in read_history_file history = self.get_reader().history File "/path/pypy/lib_pypy/pyrepl/readline.py", line 192, in get_reader console = UnixConsole(self.f_in, self.f_out, encoding=ENCODING) File "/path/pypy/lib_pypy/pyrepl/unix_console.py", line 105, in __init__ curses.setupterm(term, self.output_fd) _minimal_curses.error: setupterm: could not find terminfo database And now for something completely different: ``do you know about a toaster with 8KB of RAM and 64KB of ROM?'' >>>> Thanks ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 28 03:32:49 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Sat, 28 Sep 2013 01:32:49 +0000 Subject: [pypy-issue] [issue1615] pypy cannot build pypy3 errors with SyntaxError In-Reply-To: <1380331969.79.0.39164369014.issue1615@bugs.pypy.org> Message-ID: <1380331969.79.0.39164369014.issue1615@bugs.pypy.org> New submission from Greg Czajkowski : I am on SUSE10 with HEAD on the repo updated today. pypy and pypy3 successfully build with cpython2.7, but pypy is not able to build pypy3 setenv LD_LIBRARY_PATH /path/libffi/lib:/usr/pkgs/openssl/1.0.1c/lib64 setenv CFLAGS "-D__GNUC__ -D__amd64__ -I /path/libffi/lib/libffi-3.0.13/include -I /usr/pkgs/openssl/1.0.1c/include -I /usr/pkgs/openssl/1.0.1c/openssl" setenv LDFLAGS "-L/path/libffi/lib -L/usr/pkgs/openssl/1.0.1c/lib64 -Wl,-rpath=/usr/pkgs/icc/13.1.3e/composer_xe_2013.5.192/compiler/lib/intel64 -limf -lsvml -lirng -lintlc" /path/pypy/pypy/goal/pypy.2.7-icc-c ../../rpython/bin/rpython --opt=jit --batch --cc=/usr/pkgs/icc/13.1.3e/bin/icc --gcrootfinder=shadowstack targetpypystandalone Traceback (most recent call last): File "app_main.py", line 72, in run_toplevel File "../../rpython/bin/rpython", line 13, in from rpython.translator.goal.translate import main File "/path/pypy/rpython/translator/goal/translate.py", line 89, in log = py.log.Producer("translation") File "/path/pypy/py/_apipkg.py", line 114, in __makeattr result = importobj(modpath, attrname) File "/path/pypy/py/_apipkg.py", line 37, in importobj module = __import__(modpath, None, None, ['__doc__']) File "/path/pypy/py/_log/log.py", line 184, in setattr(Syslog, _prio, getattr(py.std.syslog, _prio)) File "/path/pypy/py/_std.py", line 13, in __getattr__ m = __import__(name) File "/path/pypy/lib_pypy/syslog.py", line 68, in lib = ffi.verify(""" File "/path/pypy/lib_pypy/cffi/api.py", line 309, in verify from .verifier import Verifier, _caller_dir_pycache File "/path/pypy/lib_pypy/cffi/verifier.py", line 1, in import sys, os, binascii, imp, shutil File "/path/pypy/lib-python/2.7/shutil.py", line 21, in from grp import getgrnam File "/path/pypy/lib_pypy/grp.py", line 28 class struct_group(metaclass=_structseq.structseqtype): ^ SyntaxError: invalid syntax Thanks for all the quick help! ---------- messages: 6224 nosy: gcflymoto, pypy-issue priority: bug release: 2.1 status: unread title: pypy cannot build pypy3 errors with SyntaxError ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 28 10:15:09 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 28 Sep 2013 08:15:09 +0000 Subject: [pypy-issue] [issue1615] pypy cannot build pypy3 errors with SyntaxError In-Reply-To: <1380331969.79.0.39164369014.issue1615@bugs.pypy.org> Message-ID: <1380356109.36.0.359579901245.issue1615@bugs.pypy.org> Armin Rigo added the comment: Just a note, I'd be interested to know the difference of performance between pypy built with GCC and with the default --gcrootfinder=asmgcc, and pypy built with ICC and --gcrootfinder=shadowstack. ---------- nosy: +arigo status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 28 10:33:24 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 28 Sep 2013 08:33:24 +0000 Subject: [pypy-issue] [issue1606] Test failures In-Reply-To: <1379232307.33.0.259128845268.issue1606@bugs.pypy.org> Message-ID: <1380357204.82.0.824856344078.issue1606@bugs.pypy.org> Armin Rigo added the comment: Fixed some tests. Skipped as "nobody seems like fixing them": test_pypy_c.test_thread and test__pypyjson. ---------- status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 28 10:57:29 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Sat, 28 Sep 2013 08:57:29 +0000 Subject: [pypy-issue] [issue1615] pypy cannot build pypy3 errors with SyntaxError In-Reply-To: <1380331969.79.0.39164369014.issue1615@bugs.pypy.org> Message-ID: <1380358649.72.0.40971126188.issue1615@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: What is pypy.2.7-icc-c? Did you build it in the same /path/pypy/pypy/ directory? ---------- nosy: +amaury ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 28 11:37:33 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 28 Sep 2013 09:37:33 +0000 Subject: [pypy-issue] [issue1615] pypy cannot build pypy3 errors with SyntaxError In-Reply-To: <1380331969.79.0.39164369014.issue1615@bugs.pypy.org> Message-ID: <1380361053.48.0.965557593029.issue1615@bugs.pypy.org> Armin Rigo added the comment: It looks like "pypy-2.7-icc-c" is not correctly installed and trying to load things from the current checkout's "lib_pypy" directory. You cannot just compile a pypy-2.7, then switch the working copy to the py3k branch, and expect the compiled pypy-2.7 to continue to work: it needs its own standard library. You must either install it fully, or use a different working copy. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 28 12:57:58 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 28 Sep 2013 10:57:58 +0000 Subject: [pypy-issue] [issue1616] Tkinter code bug In-Reply-To: <1380365878.08.0.997710451714.issue1616@bugs.pypy.org> Message-ID: <1380365878.08.0.997710451714.issue1616@bugs.pypy.org> New submission from Armin Rigo : lib_pypy/_tkinter/tclobj.py:FromObj: The function above uses the "result" local variable before it is defined, at various places. It crashes e.g. running the following example code: from Tkinter import * tk=Tk() tk.grid_propagate() ---------- messages: 6229 nosy: arigo, pypy-issue priority: bug status: unread title: Tkinter code bug ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 28 18:37:13 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Sat, 28 Sep 2013 16:37:13 +0000 Subject: [pypy-issue] [issue1616] Tkinter code bug In-Reply-To: <1380365878.08.0.997710451714.issue1616@bugs.pypy.org> Message-ID: <1380386233.85.0.168526554998.issue1616@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: Yes, those "return result" statements are more like "implement me" markers. I cannot reproduce the failure though. Here is a blind fix. ---------- nosy: +amaury status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sat Sep 28 18:54:02 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Sat, 28 Sep 2013 16:54:02 +0000 Subject: [pypy-issue] [issue1616] Tkinter code bug In-Reply-To: <1380365878.08.0.997710451714.issue1616@bugs.pypy.org> Message-ID: <1380387242.08.0.817641348701.issue1616@bugs.pypy.org> Armin Rigo added the comment: The patch helps, checking it in now. Why can't you reproduce? The three-line example works even before for you?? Strange... ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Sun Sep 29 12:14:21 2013 From: tracker at bugs.pypy.org (mattip) Date: Sun, 29 Sep 2013 10:14:21 +0000 Subject: [pypy-issue] [issue1559] Patch for PyArray_* interface by Stefan Mueller In-Reply-To: <1380449661.97.0.463441453524.issue1559@bugs.pypy.org> Message-ID: <1380449661.97.0.463441453524.issue1559@bugs.pypy.org> New submission from mattip : merged as pypy-pyarray branch ---------- nosy: +mattip status: unread -> resolved ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 30 00:42:49 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Sun, 29 Sep 2013 22:42:49 +0000 Subject: [pypy-issue] [issue1615] pypy cannot build pypy3 errors with AssertionError In-Reply-To: <1380331969.79.0.39164369014.issue1615@bugs.pypy.org> Message-ID: <1380494569.61.0.337565251212.issue1615@bugs.pypy.org> Greg Czajkowski added the comment: >What is pypy.2.7-icc-c Its pypy build with Intel Compiler >You cannot just compile a pypy-2.7, then switch the working copy to the py3k branch, and expect the compiled pypy-2.7 to continue to work: it needs its own standard library. Thanks Armin for the insight.. so here is pypy building pypy3 on py3k branch.. [platform:execute] /usr/pkgs/gcc/4.8.1/bin/gcc /tmp/usession-unknown-41/platcheck_6.o -pthread -L/path/libffi.gcc/lib64 -L/usr/pkgs/openssl/1.0.1c/lib64 -lrt -o /tmp/usession-unknown-41/platcheck_6 Traceback (most recent call last): File "app_main.py", line 72, in run_toplevel File "../../rpython/bin/rpython", line 20, in main() File "/path/pypy3/rpython/translator/goal/translate.py", line 219, in main targetspec_dic, translateconfig, config, args = parse_options_and_load_target() File "/path/pypy3/rpython/translator/goal/translate.py", line 181, in parse_options_and_load_target targetspec_dic['handle_config'](config, translateconfig) File "targetpypystandalone.py", line 205, in handle_config from pypy.objspace.std import multimethod File "/path/pypy3/pypy/objspace/std/__init__.py", line 1, in from pypy.objspace.std.objspace import StdObjSpace File "/path/pypy3/pypy/objspace/std/objspace.py", line 19, in from pypy.objspace.std.complexobject import W_ComplexObject File "/path/pypy3/pypy/objspace/std/complexobject.py", line 11, in from rpython.rlib import jit, rcomplex File "/path/pypy3/rpython/rlib/rcomplex.py", line 4, in from rpython.rlib.constant import DBL_MIN, CM_SCALE_UP, CM_SCALE_DOWN File "/path/pypy3/rpython/rlib/constant.py", line 21, in assert isinf(DBL_MAX * 1.0001) AssertionError ---------- title: pypy cannot build pypy3 errors with SyntaxError -> pypy cannot build pypy3 errors with AssertionError ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 30 01:03:20 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Sun, 29 Sep 2013 23:03:20 +0000 Subject: [pypy-issue] [issue1615] pypy cannot build pypy3 errors with AssertionError In-Reply-To: <1380331969.79.0.39164369014.issue1615@bugs.pypy.org> Message-ID: <1380495800.54.0.255098237097.issue1615@bugs.pypy.org> Greg Czajkowski added the comment: Armin how do I benchmark pypy? Install https://bitbucket.org/pypy/benchmarks ?? Thanks, Greg ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 30 06:39:25 2013 From: tracker at bugs.pypy.org (Alex Gaynor) Date: Mon, 30 Sep 2013 04:39:25 +0000 Subject: [pypy-issue] [issue1617] Deleted local variables show up in locals() In-Reply-To: <1380515965.56.0.45393204994.issue1617@bugs.pypy.org> Message-ID: <1380515965.56.0.45393204994.issue1617@bugs.pypy.org> New submission from Alex Gaynor : Specifically, if you call locals(), delete a local var, and then call locals() again, it's still present: def main(): a = 3 locals() del a print locals() main() The cause is at pypy/interpreter/eval.py fast2locals:L110 ---------- messages: 6235 nosy: agaynor, pypy-issue priority: bug status: unread title: Deleted local variables show up in locals() ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 30 06:47:04 2013 From: tracker at bugs.pypy.org (Alex Gaynor) Date: Mon, 30 Sep 2013 04:47:04 +0000 Subject: [pypy-issue] [issue1617] Deleted local variables show up in locals() In-Reply-To: <1380515965.56.0.45393204994.issue1617@bugs.pypy.org> Message-ID: <1380516424.84.0.984533333284.issue1617@bugs.pypy.org> Alex Gaynor added the comment: Fixed in 8940f38137e1 ---------- status: unread -> chatting ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 30 08:45:54 2013 From: tracker at bugs.pypy.org (Armin Rigo) Date: Mon, 30 Sep 2013 06:45:54 +0000 Subject: [pypy-issue] [issue1615] pypy cannot build pypy3 errors with AssertionError In-Reply-To: <1380331969.79.0.39164369014.issue1615@bugs.pypy.org> Message-ID: <1380523554.23.0.616738706143.issue1615@bugs.pypy.org> Armin Rigo added the comment: What is DBL_MAX? What is DBL_MAX * 1.0001 ? ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 30 10:00:18 2013 From: tracker at bugs.pypy.org (Amaury Forgeot d'Arc) Date: Mon, 30 Sep 2013 08:00:18 +0000 Subject: [pypy-issue] [issue1615] pypy cannot build pypy3 errors with AssertionError In-Reply-To: <1380331969.79.0.39164369014.issue1615@bugs.pypy.org> Message-ID: <1380528018.9.0.39265502376.issue1615@bugs.pypy.org> Amaury Forgeot d'Arc added the comment: I've heard that ICC enables fast-math by default. That's an issue here -- some IEEE-specified behavior will be incorrect. You should play with the "-fp-model" option of ICC and see which ones give correct results. ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 30 19:43:24 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Mon, 30 Sep 2013 17:43:24 +0000 Subject: [pypy-issue] [issue1615] pypy cannot build pypy3 errors with AssertionError In-Reply-To: <1380331969.79.0.39164369014.issue1615@bugs.pypy.org> Message-ID: <1380563003.99.0.666002459134.issue1615@bugs.pypy.org> Greg Czajkowski added the comment: I am getting this assertion when building with a GCC build pypy, and compiling with GCC [platform:execute] /usr/gcc/4.8.1/bin/gcc /tmp/usession-unknown-45/platcheck_7.o -pthread -L/path/libffi.gcc/lib64 -L/usr/pkgs/openssl/1.0.1c/lib64 -lrt -o /tmp/usession-unknown-45/platcheck_7 Traceback (most recent call last): File "app_main.py", line 72, in run_toplevel File "../../rpython/bin/rpython", line 20, in main() File "/path/pypy/rpython/translator/goal/translate.py", line 219, in main targetspec_dic, translateconfig, config, args = parse_options_and_load_target() File "/path/pypy/rpython/translator/goal/translate.py", line 181, in parse_options_and_load_target targetspec_dic['handle_config'](config, translateconfig) File "targetpypystandalone.py", line 201, in handle_config from pypy.objspace.std import multimethod File "/path/pypy/pypy/objspace/std/__init__.py", line 1, in from pypy.objspace.std.objspace import StdObjSpace File "/path/pypy/pypy/objspace/std/objspace.py", line 18, in from pypy.objspace.std.complexobject import W_ComplexObject File "/path/pypy/pypy/objspace/std/complexobject.py", line 11, in from rpython.rlib import jit, rcomplex File "/path/pypy/rpython/rlib/rcomplex.py", line 4, in from rpython.rlib.constant import DBL_MIN, CM_SCALE_UP, CM_SCALE_DOWN File "/path/pypy/rpython/rlib/constant.py", line 20, in assert 0.0 < DBL_MAX < (1e200*1e200) AssertionError ________________________________________ PyPy bug tracker ________________________________________ From tracker at bugs.pypy.org Mon Sep 30 23:14:11 2013 From: tracker at bugs.pypy.org (Greg Czajkowski) Date: Mon, 30 Sep 2013 21:14:11 +0000 Subject: [pypy-issue] [issue1615] pypy cannot build pypy3 errors with AssertionError In-Reply-To: <1380331969.79.0.39164369014.issue1615@bugs.pypy.org> Message-ID: <1380575651.93.0.473703784223.issue1615@bugs.pypy.org> Greg Czajkowski added the comment: I removed all paths and mentions to ICC and it's shared libs and now the build is flying fast. Thanks for the assistance. ---------- status: chatting -> resolved ________________________________________ PyPy bug tracker ________________________________________