Mailman 3 February 2015 - pypy-issue

Issue #1993: Slow string-to-byte encoding (pypy/pypy)
by mike fc 28 Feb '15

28 Feb '15

New issue 1993: Slow string-to-byte encoding https://bitbucket.org/pypy/pypy/issue/1993/slow-string-to-byte-encoding mike fc: Depending on versions being compared, pypy is 20x slower than CPython at string to byte encoding. Using a pypy2 recent nightly and latest release pypy3 on OSX. ``` #!python python bytearray buf.encode python2.7.9 6.55 6.15 python3.4.2 0.55 0.19 pypy2 12.65 12.38 pypy3 10.7 5.99 ``` ``` #!python #!/usr/bin/env python from __future__ import print_function import time buf = "hello there" * 220000 print(len(buf)) start = time.time() for i in range(1000): p = bytearray(buf, 'ascii') delta = time.time() - start print("bytearray:", delta) start = time.time() for i in range(1000): p = buf.encode('ascii') delta = time.time() - start print("buf.encode:", delta) ```

1 0

Issue #1992: sandboxing for external function 'time' (pypy/pypy)
by Matthias Zimmermann 25 Feb '15

25 Feb '15

New issue 1992: sandboxing for external function 'time' https://bitbucket.org/pypy/pypy/issue/1992/sandboxing-for-external-function… Matthias Zimmermann: I compiled PyPy 2.5 with ``` #!bash pypy ../../rpython/bin/rpython -O2 --sandbox targetpypystandalone --withmod-time ``` When I run the sandbox and want to **import time** the error message "*Not Implemented: sandboxing for external function 'time'*" occurs. In PyPy 2.3.1 import time works.

1 0

Issue #1991: reload (sys) error (pypy/pypy)
by morphello 24 Feb '15

24 Feb '15

New issue 1991: reload (sys) error https://bitbucket.org/pypy/pypy/issue/1991/reload-sys-error morphello: Hi, please excuse my lack of knowledge. I've been running SickBeard through PyPy 2.5.0 on Windows 8.1 x64, and it runs flawlessly sans for its ability to restart. Thanks to a helpful member of the forum who is more knowledgeable than I, we've identified that PyPy isn't returning the executable on a reload. Here is a link to the thread where we discuss the issue. https://sickrage.tv/forums/forum/help-support/general-support/18501-sickrag… The program attempts to restart itself, and instead of calling pypy.exe calls py.py. This works correctly under python 2.7.9 PyPy 2.5.0: ``` #!python pypy.exe Python 2.7.8 (10f1b29a2bd2, Feb 03 2015, 00:56:13) [PyPy 2.5.0 with MSC v.1500 32 bit] on win32 Type "help", "copyright", "credits" or "license" for more information. >>>> import sys >>>> sys.executable 'c:\\Pypy25\\pypy.exe' >>>> reload(sys) <module 'sys' (built-in)> >>>> sys.executable 'py.py' ``` Python 2.7.9: ``` #!python python.exe Python 2.7.9 (default, Dec 10 2014, 12:28:03) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.executable 'c:\\Python27\\python.exe' >>> reload(sys) <module 'sys' (built-in)> >>> sys.executable 'c:\\Python27\\python.exe' ``` Thank you in advance.

1 0

Issue #1990: patch_jump_for_descr assertion failure (pypy/pypy)
by Carl Friedrich Bolz 23 Feb '15

23 Feb '15

New issue 1990: patch_jump_for_descr assertion failure https://bitbucket.org/pypy/pypy/issue/1990/patch_jump_for_descr-assertion-f… Carl Friedrich Bolz: Assertion failure in ``patch_jump_for_descr``: ``` RPython traceback: File "rpython_jit_metainterp_compile.c", line 17761, in send_bridge_to_backend File "rpython_jit_backend_x86_assembler.c", line 62107, in Assembler386_assemble_bridge File "rpython_jit_backend_x86_assembler.c", line 62778, in Assembler386_patch_jump_for_descr Fatal RPython error: AssertionError ``` It's this assert: ``` #!python def patch_jump_for_descr(self, faildescr, adr_new_target): adr_jump_offset = faildescr.adr_jump_offset assert adr_jump_offset != 0 ``` Way to reproduce: * clone and build pycket https://github.com/samth/pycket * clone the benchmarks: https://github.com/krono/pycket-bench/ * go to pycket-bench/Crossbenchmarks and run pycket-c racket/dynamic-nothing.rkt

1 0

Issue #1989: array.array creation 5x slower than CPython (pypy/pypy)
by mike fc 23 Feb '15

23 Feb '15

New issue 1989: array.array creation 5x slower than CPython https://bitbucket.org/pypy/pypy/issue/1989/arrayarray-creation-5x-slower-th… mike fc: Creating array.array objects from a buffer seems 5x slower than CPython. * pypy2 = 3.44s * pypy3 = 3.42s * CPython3.4.2 = 0.66 * CPython2.7.9 = 0.69 Using recent nightly for pypy2 and latest release for pypy3 on OSX. ``` #!python #!/usr/bin/env python from __future__ import print_function from datetime import datetime import array buf = b"hello there" * 100000 print(len(buf)) start = datetime.now() for i in range(10000): p = array.array('B', buf) delta = datetime.now() - start print("T:", delta) ```

1 0

Issue #1988: pypy3: large read will make future os.system calls fail (pypy/pypy)
by Christoph Reiter 22 Feb '15

22 Feb '15

New issue 1988: pypy3: large read will make future os.system calls fail https://bitbucket.org/pypy/pypy/issue/1988/pypy3-large-read-will-make-futur… Christoph Reiter: ``` import os open("/dev/null", "rb").read(4294967295) print(os.system("true")) ``` prints -1 instead of 0

1 0

Issue #1987: Performance degradation on PyPy 2.5.0 vs 2.4.0 (pypy/pypy)
by Jakub Głazik 19 Feb '15

19 Feb '15

New issue 1987: Performance degradation on PyPy 2.5.0 vs 2.4.0 https://bitbucket.org/pypy/pypy/issue/1987/performance-degradation-on-pypy-… Jakub Głazik: We are observing around 10% higher CPU usage on PyPy 2.5 vs 2.4 The workload is a HTTP loadbalancer process serving around 700 API requests per second. ![Zrzut ekranu 2015-02-19 o 21.01.38.png](https://bitbucket.org/repo/R7AbB/images/2512960297-Zrzut%20ek… The graph presents three instances of a loadbalancer, each participating in a round robin fasion (behind AWS ELB). The top one is running PyPy 2.5, bottom two are on PyPy 2.4. Sorry for lack of real legend in this graph. The code that is being run: https://github.com/futuresimple/mantrid

1 0

Issue #1986: More improvements for pyrepl (pypy/pypy)
by Armin Rigo 19 Feb '15

19 Feb '15

New issue 1986: More improvements for pyrepl https://bitbucket.org/pypy/pypy/issue/1986/more-improvements-for-pyrepl Armin Rigo: A follow-up for issue #1978, based on feedback at http://bugs.python.org/issue23441. Improve the pyrepl prompt of PyPy by using the following two simple behaviors that are common in text editors: * "backspace" should dedent by removing sometimes more than 1 space at once * "enter" should automatically indent the new line as much as the previous one

1 0

Issue #1985: PyPy default doesn't compile on OS X (pypy/pypy)
by Alex Gaynor 15 Feb '15

15 Feb '15

New issue 1985: PyPy default doesn't compile on OS X https://bitbucket.org/pypy/pypy/issue/1985/pypy-default-doesnt-compile-on-o… Alex Gaynor: This is because the OpenSSL included, 0.9.8, does not define `SSL_OP_NO_COMPRESSION`. PyPy should expose this symbol only if it's defined.

1 0

Issue #1984: Continulet switch results in a segfault (pypy/pypy)
by Jakub Stasiak 14 Feb '15

14 Feb '15

New issue 1984: Continulet switch results in a segfault https://bitbucket.org/pypy/pypy/issue/1984/continulet-switch-results-in-a-s… Jakub Stasiak: This is a piece of code that crashes PyPy 2.4.0, 2.5.0 and version built from the latest source code (I didn't write it like this, this is a test case I managed to isolate starting with something larger). It segfaults every time I run it on OS X 10.9.5 (homebrew build and my own builds) and Ubuntu 14.04 (official Linux x64 packages). ``` #!python from _continuation import continulet c1 = continulet.__new__(continulet) c2 = continulet(lambda g: None) continulet.switch(c1, to=c2) continulet.switch(c1, to=c2) ``` lldb session (OS X, using pyinteractive, latest source code): ``` * thread #1: tid = 0x782cc, 0x00000001031fd9d8 externmod_0.dylib`stacklet_switch + 24, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1f) frame #0: 0x00000001031fd9d8 externmod_0.dylib`stacklet_switch + 24 externmod_0.dylib`stacklet_switch + 24: -> 0x1031fd9d8: movq 0x20(%r14), %rbx 0x1031fd9dc: leaq (%rsp), %rax 0x1031fd9e0: cmpq %rax, 0x8(%rbx) 0x1031fd9e4: ja 0x1031fd9ef ; stacklet_switch + 47 (lldb) disassemble externmod_0.dylib`stacklet_switch: 0x1031fd9c0: pushq %r14 0x1031fd9c2: pushq %rbx 0x1031fd9c3: pushq %rax 0x1031fd9c4: movq %rdi, %r14 0x1031fd9c7: leaq 0x38e(%rip), %rdi ; "Got target %p\n\n" 0x1031fd9ce: xorl %eax, %eax 0x1031fd9d0: movq %r14, %rsi 0x1031fd9d3: callq 0x1031fdd18 ; symbol stub for: printf -> 0x1031fd9d8: movq 0x20(%r14), %rbx 0x1031fd9dc: leaq (%rsp), %rax 0x1031fd9e0: cmpq %rax, 0x8(%rbx) 0x1031fd9e4: ja 0x1031fd9ef ; stacklet_switch + 47 0x1031fd9e6: leaq 0x1(%rsp), %rax 0x1031fd9eb: movq %rax, 0x8(%rbx) 0x1031fd9ef: movq %r14, 0x20(%rbx) 0x1031fd9f3: leaq 0x26(%rip), %rdi ; g_save_state 0x1031fd9fa: leaq 0x11f(%rip), %rsi ; g_restore_state 0x1031fda01: movq %rbx, %rdx 0x1031fda04: callq *0x62e(%rip) ; _stacklet_switchstack 0x1031fda0a: movq 0x18(%rbx), %rax 0x1031fda0e: addq $0x8, %rsp 0x1031fda12: popq %rbx 0x1031fda13: popq %r14 0x1031fda15: retq 0x1031fda16: nopw %cs:(%rax,%rax) (lldb) register read General Purpose Registers: rax = 0x000000000000001f rbx = 0x00007fff5fbfac10 rcx = 0xd8001e3171326a64 rdx = 0x00007fff71227638 __sFX + 248 rdi = 0x0000040000000503 rsi = 0x0000050000000500 rbp = 0x00007fff5fbfab00 rsp = 0x00007fff5fbfaae0 r8 = 0x0000000000000040 r9 = 0x00007fff5fbfa900 r10 = 0x00000001031fdd0a externmod_0.dylib`symbol stub for: free + 4 r11 = 0x0000000000000246 r12 = 0x00007fff5fbfaa50 r13 = 0x0000000000000001 r14 = 0xffffffffffffffff r15 = 0x00007fff7122e420 libsystem_c.dylib`__stack_chk_guard rip = 0x00000001031fd9d8 externmod_0.dylib`stacklet_switch + 24 rflags = 0x0000000000010206 cs = 0x000000000000002b fs = 0x0000000000000000 gs = 0x0000000000000000 (lldb) thread backtrace * thread #1: tid = 0x782cc, 0x00000001031fd9d8 externmod_0.dylib`stacklet_switch + 24, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1f) * frame #0: 0x00000001031fd9d8 externmod_0.dylib`stacklet_switch + 24 frame #1: 0x000000010310c7ef _ctypes.so`ffi_call_unix64 + 79 frame #2: 0x000000010310d00b _ctypes.so`ffi_call + 815 frame #3: 0x00000001031085a3 _ctypes.so`_ctypes_callproc + 643 frame #4: 0x0000000103102aee _ctypes.so`PyCFuncPtr_call + 1092 frame #5: 0x000000010000f0ea Python`PyObject_Call + 99 frame #6: 0x000000010008b97b Python`PyEval_EvalFrameEx + 10701 frame #7: 0x0000000100088d7a Python`PyEval_EvalCodeEx + 1409 frame #8: 0x000000010008f59d Python`fast_function + 117 frame #9: 0x000000010008c400 Python`PyEval_EvalFrameEx + 13394 frame #10: 0x0000000100088d7a Python`PyEval_EvalCodeEx + 1409 frame #11: 0x000000010002d1ae Python`function_call + 350 frame #12: 0x000000010000f0ea Python`PyObject_Call + 99 frame #13: 0x000000010008b97b Python`PyEval_EvalFrameEx + 10701 frame #14: 0x0000000100088d7a Python`PyEval_EvalCodeEx + 1409 frame #15: 0x000000010002d1ae Python`function_call + 350 frame #16: 0x000000010000f0ea Python`PyObject_Call + 99 frame #17: 0x0000000100019ed7 Python`instancemethod_call + 174 frame #18: 0x000000010000f0ea Python`PyObject_Call + 99 frame #19: 0x000000010005580f Python`slot_tp_call + 61 frame #20: 0x000000010000f0ea Python`PyObject_Call + 99 (...) ``` I'm not familiar with the codebase but I did some digging, here's what I found out so far (starting from the newest frame): * ``stacklet_switch`` is called with ``target == 0xffffffffffffffff`` (https://bitbucket.org/pypy/pypy/src/7db3e6dd2efea611997d981f5738988a84f856c…) * Opaque pointer with that value comes from /in my case, I imagine it can vary/ ``StackletGcRootFinder .switch`` (https://bitbucket.org/pypy/pypy/src/7db3e6dd2efea611997d981f5738988a84f856c…) * That's passed there by ``StackletThread.switch`` (https://bitbucket.org/pypy/pypy/src/7db3e6dd2efea611997d981f5738988a84f856c…) * Passed there by ``W_Continulet.switch`` (https://bitbucket.org/pypy/pypy/src/7db3e6dd2efea611997d981f5738988a84f856c…) and this is in turn because ``w_to`` contains ``<* <C object None (opaque) at 0xffffffffffffffff>>`` For all intents and purposes release build debug session looks the same, the only notable exception is with the release version ``switch`` is called with target pointer equal to 0x0000000000000000 rather than 0xffffffffffffffff.

1 0