From issues-reply at bitbucket.org Wed Mar 4 12:02:38 2015 From: issues-reply at bitbucket.org (mattip) Date: Wed, 04 Mar 2015 11:02:38 -0000 Subject: [pypy-issue] Issue #1994: _numpypy argsort segfaults (pypy/pypy) Message-ID: <20150304110238.5179.56306@app05.ash-private.bitbucket.org> New issue 1994: _numpypy argsort segfaults https://bitbucket.org/pypy/pypy/issue/1994/_numpypy-argsort-segfaults mattip: This was reported as pypy/numpy issue #19 but actually is a pypy problem. Running this code crashes when the JIT kicks in after warmup:: import _numpypy.multiarray as np import random a=np.empty(256) for i in range(256): a[i] = random.random() for i in range(10000): a.argsort() From issues-reply at bitbucket.org Mon Mar 9 17:00:53 2015 From: issues-reply at bitbucket.org (Lisandro Dalcin) Date: Mon, 09 Mar 2015 16:00:53 -0000 Subject: [pypy-issue] Issue #1995: PyPy3: pickle.dumps(-2**63) hangs forever (pypy/pypy) Message-ID: <20150309160053.19800.91343@app05.ash-private.bitbucket.org> New issue 1995: PyPy3: pickle.dumps(-2**63) hangs forever https://bitbucket.org/pypy/pypy/issue/1995/pypy3-pickledumps-2-63-hangs-forever Lisandro Dalcin: Could any of you please try to reproduce this? ``` #!shell $ cat pkl.py import pickle print(pickle.dumps(-2**63+1)) print(pickle.dumps(-2**63-1)) print(pickle.dumps(-2**63)) $ pypy3 pkl.py b'\x80\x03\x8a\x08\x01\x00\x00\x00\x00\x00\x00\x80.' b'\x80\x03\x8a\t\xff\xff\xff\xff\xff\xff\xff\x7f\xff.' ``` and then the interpreter hangs forever. From issues-reply at bitbucket.org Wed Mar 11 12:19:29 2015 From: issues-reply at bitbucket.org (jimhorng) Date: Wed, 11 Mar 2015 11:19:29 -0000 Subject: [pypy-issue] Issue #1996: Segmentation fault when calling X509.load_request_string in pypy env (pypy/pypy) Message-ID: <20150311111929.6166.67078@app04.ash-private.bitbucket.org> New issue 1996: Segmentation fault when calling X509.load_request_string in pypy env https://bitbucket.org/pypy/pypy/issue/1996/segmentation-fault-when-calling jimhorng: Originated from [SOF](http://stackoverflow.com/questions/28961005/segmentation-fault-when-calling-x509-load-request-string-in-pypy-env?noredirect=1#comment46211517_28961005) Although in [pypy compatibility list][1] says the M2Crypto is supported, but I got `segmentation fault` after run less than 100 times in a loop. my code similar as below: ``` #!python TIMES = 1000 def main(): csr_b64 = 'MIICpjCCAY4CAQAwYTELMAkGA1UEBhMCVFcxETAPBgNVBAMMCHRlc3QuY29tMQ0wCwYDVQQHDAREYWFuMRAwDgYDVQQKDAd0ZXN0MTIzMQwwCgYDVQQIDANUUEUxEDAOBgNVBAsMB3Rlc3QxMjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9oICQhxQXBUEoPZZIvtlh5j+D7UeczK7MeVRXAlvw1s+ByhnFZsay8EtsV5DmhSl2w3y/qAIlZGdhqsCsNcK1RrE/eMXrrQ+pdRDZdrktqZUygniRD7kDRZRmqgh8+4eEz8sw1I52V/oW98M3yQBKN1gTCYO1bJiWG7PcM4b0fNqEkZQg6lwNyZo710dpu37kOHm1G0FFKtqTCmyYeuhRJVru/QWpvRaBnPZcxHlSfSv+ye0DKnJ0tQkBjL4PWsVOlPoJNp9gZJ0k9Xtfoj75ypa42LAp4HE61hpZw+TIjHW97tVxhrgL4LvjhPXYntGq0TrIold2/TfJ7reSf13BAgMBAAGgADANBgkqhkiG9w0BAQsFAAOCAQEARNeF8Kkn9pZC6pNuEnYfrtoh2HUJB9VX6nuTWnvJDSh9DG2we++Iaq6OQIVl5MBoamm4xdWYKE8UK9MZ5JvXGcXMrOoI4xAjvsdxMylFQ/bH3Fbv6DA4NOPsQidTEpEPLqslPXlTwV3dbL/+hBzjVtDsg/BeAOO4be2X9DdM+Du0tycROGfBVbObNW/+BpHhnyyr0qs6/wkdIE6ppjrCiv7HM1pZe/l8Po9Ej5z368y6tdL+4PCrVc/AnWiyLtp9QW6krqn/0vgReO7dbzrMB79FUBV1K9XxlWOZDpI2UcW8biOsrUJC3AQZwR0KIyi+YsVmoMHSxY2pfaRMjPT6kQ==' # csr_b64 = 'abc' for i in xrange(TIMES): csr = convert_csr_b64_to_csr(csr_b64) domain_name = csr.get_subject().CN print("%s: domain_name: %s" % (i, domain_name)) import time time.sleep(10) def convert_csr_b64_to_csr(csr_b64): from M2Crypto import X509 import textwrap csr_pem = textwrap.fill(csr_b64, 64) csr_pem = ('-----BEGIN CERTIFICATE REQUEST-----\n' + csr_pem + '\n-----END CERTIFICATE REQUEST-----') csr = X509.load_request_string(csr_pem, X509.FORMAT_PEM) return csr if __name__ == "__main__": main() ``` dependencies tried: * M2Crypto==0.22.3 * Mac OS X, pypy:2.4.0, SWIG:3.0.2 * Centos 6, pypy:2.3.1, SWIG:1.3.40 * Linux64, pypy:2.5.0 Thanks for any advise :) From issues-reply at bitbucket.org Sat Mar 14 21:57:55 2015 From: issues-reply at bitbucket.org (thomasballinger) Date: Sat, 14 Mar 2015 20:57:55 -0000 Subject: [pypy-issue] Issue #1997: PyPy3: curses.initscr() raises ctype TypeError (pypy/pypy) Message-ID: <20150314205755.5443.48139@app09.ash-private.bitbucket.org> New issue 1997: PyPy3: curses.initscr() raises ctype TypeError https://bitbucket.org/pypy/pypy/issue/1997/pypy3-cursesinitscr-raises-ctype-typeerror thomasballinger: Leads on from https://bitbucket.org/pypy/pypy/issue/1946/pypy3-cursesinitscr-raises-ctype-typeerror. In addition to https://bitbucket.org/pypy/pypy/commits/d8475a6257bc it seems https://bitbucket.org/thomasballinger/pypy/commits/d71a17fd7039c9588e5121ab1cf2300e03589645 is necessary to make things like blessings work. ``` (bpythonpypy3)tom-mba:bpython tomb$ python --version Python 3.2.5 (b2091e973da69152b3f928bfaabd5d2347e6df46, Dec 15 2014, 08:54:30) [PyPy 2.4.0 with GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] (bpythonpypy3)tom-mba:bpython tomb$ cat test.py import blessings term = blessings.Terminal() print(term.clear_eos) (bpythonpypy3)tom-mba:bpython tomb$ python test.py Traceback (most recent call last): File "test.py", line 3, in print(term.clear_eos) File "/Users/tomb/.virtualenvs/bpythonpypy3/site-packages/blessings/__init__.py", line 175, in __getattr__ resolution = (self._resolve_formatter(attr) if self.does_styling File "/Users/tomb/.virtualenvs/bpythonpypy3/site-packages/blessings/__init__.py", line 368, in _resolve_formatter return ParametrizingString(self._resolve_capability(attr)) File "/Users/tomb/.virtualenvs/bpythonpypy3/site-packages/blessings/__init__.py", line 378, in _resolve_capability code = tigetstr(self._sugar.get(atom, atom)) File "/usr/local/Cellar/pypy3/2.4.0/libexec/lib_pypy/_curses.py", line 1360, in tigetstr val = lib.tigetstr(capname) TypeError: initializer for ctype 'char *' must be a bytes or list or tuple, not str (bpythonpypy3)tom-mba:bpython tomb$ ``` See also https://github.com/bpython/bpython/issues/502#issuecomment-80511264 From issues-reply at bitbucket.org Mon Mar 16 16:36:50 2015 From: issues-reply at bitbucket.org (Vadim Markovtsev) Date: Mon, 16 Mar 2015 15:36:50 -0000 Subject: [pypy-issue] Issue #1998: numpy.zeros(0, numpy.float32).dtype in (numpy.float32, numpy.float64) is False (pypy/pypy) Message-ID: <20150316153650.13539.98006@app10.ash-private.bitbucket.org> New issue 1998: numpy.zeros(0, numpy.float32).dtype in (numpy.float32, numpy.float64) is False https://bitbucket.org/pypy/pypy/issue/1998/numpyzeros-0-numpyfloat32-dtype-in Vadim Markovtsev: ``` #!python import numpy numpy.zeros(0, numpy.float32).dtype in (numpy.float32, numpy.float64) ``` CPython returns True, while PyPy returns False. Numerous assertions in my large scientific app fail because of that. From issues-reply at bitbucket.org Tue Mar 17 08:59:21 2015 From: issues-reply at bitbucket.org (Vadim Markovtsev) Date: Tue, 17 Mar 2015 07:59:21 -0000 Subject: [pypy-issue] Issue #1999: cffi must use file locks (pypy/pypy) Message-ID: <20150317075921.7245.27412@app08.ash-private.bitbucket.org> New issue 1999: cffi must use file locks https://bitbucket.org/pypy/pypy/issue/1999/cffi-must-use-file-locks Vadim Markovtsev: Please read [GitHub/Pillow issue 1135](https://github.com/python-pillow/Pillow/issues/1135) first. The problem is, some packages are compiled with cffi lazily, during the very first import. Doing so in multiple processes at the same time can lead to permanent (and silent!) deadlock. This is what's happening with Pillow or any other similar package. I suggest pypy's cffi to acquire a file lock and fail / wait until it's deleted, if it exists. The behavior is similar to Debian's apt or git index locks. From issues-reply at bitbucket.org Tue Mar 17 15:29:32 2015 From: issues-reply at bitbucket.org (Antonio Cuni) Date: Tue, 17 Mar 2015 14:29:32 -0000 Subject: [pypy-issue] Issue #2000: bytecode changed but pyc version didn't in pypy 2.5.x (pypy/pypy) Message-ID: <20150317142932.7337.82052@app13.ash-private.bitbucket.org> New issue 2000: bytecode changed but pyc version didn't in pypy 2.5.x https://bitbucket.org/pypy/pypy/issue/2000/bytecode-changed-but-pyc-version-didnt-in Antonio Cuni: PyPy 2.5.x compiles the statement ```exec(src, d)``` (i.e., when passing a tuple) differently than PyPy 2.5.0 and CPython. However, the pyc version is the same, which results in an exception when trying to import a pyc which was compiled with a previous version of PyPy. To reproduce, create a file named ```execbug.py``` ``` #!python import sys import dis def foo(src, d): exec(src, d) print sys.version dis.dis(foo) foo('None', {}) print 'ALL OK' ``` Then, make sure that exebug.pyc does NOT exist, and execute the following with PyPy 2.5.0: ``` $ /tmp/pypy-2.5.0-linux64/bin/pypy -c 'import execbug' 2.7.8 (10f1b29a2bd2, Feb 02 2015, 21:22:43) [PyPy 2.5.0 with GCC 4.6.3] 5 0 LOAD_FAST 0 (src) 3 LOAD_FAST 1 (d) 6 BUILD_TUPLE 2 9 LOAD_CONST 0 (None) 12 DUP_TOP 13 EXEC_STMT 14 LOAD_CONST 0 (None) 17 RETURN_VALUE ALL OK ``` Now, if you try with pypy 2.5.1 (as well as the current trunk): ``` 2.7.9 (5aed0a41060e, Mar 17 2015, 05:46:24) [PyPy 2.5.1 with GCC 4.6.3] 5 0 LOAD_FAST 0 (src) 3 LOAD_FAST 1 (d) 6 BUILD_TUPLE 2 9 LOAD_CONST 0 (None) 12 DUP_TOP 13 EXEC_STMT 14 LOAD_CONST 0 (None) 17 RETURN_VALUE Traceback (most recent call last): File "//app_main.py", line 75, in run_toplevel File "//app_main.py", line 588, in run_it File "", line 1, in File "execbug.py", line 9, in foo('None', {}) File "execbug.py", line 5, in foo exec(src, d) TypeError: exec: arg 1 must be a string, file, or code object ``` If you remove the .pyc, pypy 2.5.1 works well (note that the bytecode is different, not sure why) ``` $ /tmp/pypy-c-jit-76420-5aed0a41060e-linux64/bin/pypy -c 'import execbug' 2.7.9 (5aed0a41060e, Mar 17 2015, 05:46:24) [PyPy 2.5.1 with GCC 4.6.3] 5 0 LOAD_FAST 0 (src) 3 LOAD_FAST 1 (d) 6 DUP_TOP 7 EXEC_STMT 8 LOAD_CONST 0 (None) 11 RETURN_VALUE ALL OK ``` This is a serious bug, because it triggers random errors if someone upgrades from PyPy 2.5.0 to 2.5.1. Note that this also breaks code like ```x=('None', {}); exec x```, which works fine on CPython and PyPy up to 2.5.0 From issues-reply at bitbucket.org Tue Mar 17 23:19:23 2015 From: issues-reply at bitbucket.org (David MacIver) Date: Tue, 17 Mar 2015 22:19:23 -0000 Subject: [pypy-issue] Issue #2001: Segfault / Invalid RPython instruction when importing code with native libraries under ulimit (pypy/pypy) Message-ID: <20150317221923.29557.96175@app14.ash-private.bitbucket.org> New issue 2001: Segfault / Invalid RPython instruction when importing code with native libraries under ulimit https://bitbucket.org/pypy/pypy/issue/2001/segfault-invalid-rpython-instruction-when David MacIver: I get a segfault when doing the following: 1. Set a ulimit with "ulimit -v 150000 -v 150000" 2. Run py.test on a file containing just the following two lines: ``` #!python import sqlite3 import json ``` On both a nightly build and the 2.5.0 release this segfaults. On a nightly with the binaries replaced with ones with assertions enabled I get "Invalid RPython operation (NULL ptr or bad array index)" From issues-reply at bitbucket.org Wed Mar 18 19:18:32 2015 From: issues-reply at bitbucket.org (David MacIver) Date: Wed, 18 Mar 2015 18:18:32 -0000 Subject: [pypy-issue] Issue #2002: sqlite connection handles not getting garbage collected without close (pypy/pypy) Message-ID: <20150318181832.25952.69818@app09.ash-private.bitbucket.org> New issue 2002: sqlite connection handles not getting garbage collected without close https://bitbucket.org/pypy/pypy/issue/2002/sqlite-connection-handles-not-getting David MacIver: The following code runs in bounded memory in cpython and just continually allocates an never frees it in pypy: ``` #!python import sqlite3 while True: sqlite3.connect(":memory:") ``` If you close the connection pypy also runs in bounded memory. The [Pep 249 Spec](https://www.python.org/dev/peps/pep-0249/) suggests that close is supposed to happen in __del__, though the sqlite3 API doesn't explicitly say that this happens. I know pypy doesn't do deterministic destruction, but it doesn't look like this is ever getting its destructor called. From issues-reply at bitbucket.org Thu Mar 19 10:55:38 2015 From: issues-reply at bitbucket.org (Maciej Fijalkowski) Date: Thu, 19 Mar 2015 09:55:38 -0000 Subject: [pypy-issue] Issue #2003: --output checks for overriding pypy-c don't work (pypy/pypy) Message-ID: <20150319095538.23661.41718@app03.ash-private.bitbucket.org> New issue 2003: --output checks for overriding pypy-c don't work https://bitbucket.org/pypy/pypy/issue/2003/output-checks-for-overriding-pypy-c-dont Maciej Fijalkowski: When we have pypy-c and we try to do ./pypy-c rpython ..... there are complaints that we will override the running program. However when we rename pypy-c (but not libpypy-c.so, which we can't rename easily), the warning/error disappears while still being dangerous. From issues-reply at bitbucket.org Thu Mar 19 20:01:43 2015 From: issues-reply at bitbucket.org (Jacek Wielemborek) Date: Thu, 19 Mar 2015 19:01:43 -0000 Subject: [pypy-issue] Issue #2004: 2.4.0 crash while running a SAX parser (pypy/pypy) Message-ID: <20150319190143.16792.42620@app09.ash-private.bitbucket.org> New issue 2004: 2.4.0 crash while running a SAX parser https://bitbucket.org/pypy/pypy/issue/2004/240-crash-while-running-a-sax-parser Jacek Wielemborek: While trying out my SAX parser of Wikipedia dumps, I came across a SIGABRT crash that produced the attached core dump. I also attach the script. I ran the following command: ``` 7z x enwiki-20150112-pages-meta-history19.xml-p010818420p011015153.7z -so 2>/dev/null | pv -cN in | pypy sax.py | pv -lcN out >/dev/null ``` Here's the backtrace: ``` $ gdb core.21562 GNU gdb (GDB) Fedora 7.8.2-38.fc21 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... [New LWP 21562] Reading symbols from /usr/lib64/pypy-2.4.0/pypy...Reading symbols from /usr/lib/debug/usr/lib64/pypy-2.4.0/pypy.debug...done. done. Missing separate debuginfo for Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/87/63004aa1bfc30b2999e47e1c66640a5ea919f5 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `pypy sax.py'. Program terminated with signal SIGABRT, Aborted. #0 0x0000003f3de348d7 in __GI_raise (sig=sig at entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:55 55 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); Missing separate debuginfos, use: debuginfo-install expat-2.1.0-10.fc21.x86_64 libffi-3.1-7.fc21.x86_64 ncurses-libs-5.9-16.20140323.fc21.x86_64 (gdb) bt #0 0x0000003f3de348d7 in __GI_raise (sig=sig at entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x0000003f3de3653a in __GI_abort () at abort.c:89 #2 0x0000003f3de2d47d in __assert_fail_base (fmt=0x3f3df86cb8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion at entry=0x14e2ace "(rpy_fastgil != 0)", file=file at entry=0x14e2b10 "/builddir/build/BUILD/pypy-2.4.0-src/rpython/translator/c/src/thread_gil.c", line=line at entry=0x8a, function=function at entry=0x14e2df0 <__PRETTY_FUNCTION__.4962> "RPyGilYieldThread") at assert.c:92 #3 0x0000003f3de2d532 in __GI___assert_fail (assertion=assertion at entry=0x14e2ace "(rpy_fastgil != 0)", file=file at entry=0x14e2b10 "/builddir/build/BUILD/pypy-2.4.0-src/rpython/translator/c/src/thread_gil.c", line=line at entry=0x8a, function=function at entry=0x14e2df0 <__PRETTY_FUNCTION__.4962> "RPyGilYieldThread") at assert.c:101 #4 0x000000000142f236 in RPyGilYieldThread () at /usr/src/debug/pypy-2.4.0-src/rpython/translator/c/src/thread_gil.c:138 #5 0x0000000000cc5619 in pypy_g_do_yield_thread () at pypy_module_thread_gil.c:63 #6 0x0000000000787205 in pypy_g_action_dispatcher__AccessDirect_None (l_ec_7=, l_frame_16=l_frame_16 at entry=0x7fda08898a30) at pypy_interpreter_executioncontext.c:4421 #7 0x00000000007c8909 in pypy_g_dispatch_bytecode__AccessDirect_None (l_self_13841=l_self_13841 at entry=0x7fda08898a30, l_co_code_3=0x7fda081bd610, l_next_instr_4=, l_ec_18=) at pypy_interpreter_pyopcode.c:13030 #8 0x00000000007cef61 in pypy_g_handle_bytecode__AccessDirect_None (l_self_13840=l_self_13840 at entry=0x7fda08898a30, l_co_code_2=, l_next_instr_53=, l_ec_17=) at pypy_interpreter_pyopcode.c:3504 #9 0x0000000000c9fdb6 in pypy_g_portal_5 (l_next_instr_1=, l_next_instr_1 at entry=0x52, l_v4896=l_v4896 at entry=0x0, l_pycode_12=, l_self_15238=0x7fda08898a30, l_ec_9=) at pypy_module_pypyjit_interp_jit.c:300 #10 0x000000000114fd6a in pypy_g_ll_portal_runner__Unsigned_Bool_pypy_interpreter (l_stararg0_3080=, l_stararg1_2854=, l_stararg2_1378=, l_stararg2_1378 at entry=, l_stararg3_834=, l_stararg3_834 at entry=, l_stararg4_608=, l_stararg4_608 at entry=) at rpython_jit_metainterp_warmspot.c:1853 #11 0x0000000000546834 in pypy_g_call_stub_4 (l_func_127=, l_args_i_7=, l_args_r_7=, l_args_f_7=) at implement_8.c:58580 #12 0x0000000000fc0243 in pypy_g_bhimpl_jit_merge_point__star_6 (l_self_17131=0x543a, l_jdindex_7=0x543a, l_v2097422=0x6, l_stararg1_1471=0xffffffffffffffff, l_v2097425=0x3bb6c90, l_stararg3_518=0xfefefefefefefeff, l_stararg4_369=0x7fda08898c10, l_v2097423=0x7fda08898c30) at rpython_jit_metainterp_blackhole.c:43588 #13 0x0000000000fc0b3a in pypy_g_handler_jit_merge_point_1 (l_self_17043=0x543a, l_self_17043 at entry=0x7fda0846ff20, l_code_302=0x543a, l_code_302 at entry=0x1c60a00 , l_position_241=0x13) at rpython_jit_metainterp_blackhole.c:8645 #14 0x0000000000fc0fab in pypy_g_dispatch_loop (l_self_17042=l_self_17042 at entry=0x7fda0846ff20, l_code_301=0x1c60a00 , l_position_237=) at rpython_jit_metainterp_blackhole.c:4125 #15 0x0000000000fc5182 in pypy_g_BlackholeInterpreter_run (l_self_17039=l_self_17039 at entry=0x7fda0846ff20) at rpython_jit_metainterp_blackhole.c:2477 #16 0x0000000000fc5387 in pypy_g_BlackholeInterpreter__resume_mainloop (l_v2079143=0x7fda0846ff20, l_v2079152=l_v2079152 at entry=0x0) at rpython_jit_metainterp_blackhole.c:1548 #17 0x0000000000fc5738 in pypy_g__run_forever (l_blackholeinterp_0=l_blackholeinterp_0 at entry=0x7fda070942a0, l_current_exc_0=) at rpython_jit_metainterp_blackhole.c:800 #18 0x0000000000fc5e63 in pypy_g_resume_in_blackhole (l_jitdriver_sd_686=l_jitdriver_sd_686 at entry=0x1c5bec0 , l_resumedescr_4=, l_deadframe_121=, l_all_virtuals_1=l_all_virtuals_1 at entry=0x0) at rpython_jit_metainterp_blackhole.c:47894 #19 0x0000000000fd3b34 in pypy_g_ResumeGuardDescr_handle_fail (l_self_12635=, l_deadframe_128=, l_jitdriver_sd_696=0x1c5bec0 ) at rpython_jit_metainterp_compile.c:26215 #20 0x00000000012139ff in pypy_g_execute_assembler__star_3_15 (l_loop_token_126=, l_stararg0_1229=l_stararg0_1229 at entry=0x1, l_stararg1_857=l_stararg1_857 at entry=0x3dac4d6, l_stararg2_551=l_stararg2_551 at entry=0x26) at rpython_jit_metainterp_warmstate_2.c:46649 #21 0x00000000011d3520 in pypy_g_maybe_compile_and_run__star_3_15 (l_increment_threshold_154=, l_v2498716=l_v2498716 at entry=0x1, l_v2498715=l_v2498715 at entry=0x3dac4d6 "2602:306:3B6E:16B0:8DB1:DAFD:D4A1:A711\n \n minor grammar edit.\n wikitext\n text/x-wiki\n \n \n minor grammar edit.\n wikitext\n text/x-wiki\n \n \n minor grammar edit.\n wikitext to continue, or q to quit--- del>\n text/x-wiki\n \n \n minor grammar edit.\n wikitext\n text/x-wiki\n New issue 2005: RPython OSError if you os.close() the wrong fd https://bitbucket.org/pypy/pypy/issue/2005/rpython-oserror-if-you-osclose-the-wrong Antonio Cuni: Suppose to have the following bar.py and foo.py ``` #!python # bar.py import foo # foo.py import os os.close(3) # fd 3 points to foo.py ``` On CPython, it works fine; on PyPy, it crashes: ``` $ pypy bar.py RPython traceback: File "pypy_goal_targetpypystandalone.c", line 2206, in entry_point File "pypy_interpreter_pyframe.c", line 3185, in PyFrame_execute_frame File "rpython_jit_metainterp_warmspot.c", line 1858, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit_interp_jit.c", line 289, in portal_5 File "pypy_interpreter_pyopcode.c", line 3468, in handle_bytecode__AccessDirect_None File "pypy_interpreter_pyopcode.c", line 7012, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_pyopcode.c", line 31276, in call_function__AccessDirect_None File "pypy_interpreter_pyframe.c", line 3185, in PyFrame_execute_frame File "rpython_jit_metainterp_warmspot.c", line 1858, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit_interp_jit.c", line 289, in portal_5 File "pypy_interpreter_pyopcode.c", line 3468, in handle_bytecode__AccessDirect_None File "pypy_interpreter_pyopcode.c", line 7050, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_pyopcode.c", line 31276, in call_function__AccessDirect_None File "pypy_interpreter_pyframe.c", line 3185, in PyFrame_execute_frame File "rpython_jit_metainterp_warmspot.c", line 1858, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit_interp_jit.c", line 289, in portal_5 File "pypy_interpreter_pyopcode.c", line 3468, in handle_bytecode__AccessDirect_None File "pypy_interpreter_pyopcode.c", line 7099, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_pyopcode.c", line 31276, in call_function__AccessDirect_None File "pypy_interpreter_pyframe.c", line 3185, in PyFrame_execute_frame File "rpython_jit_metainterp_warmspot.c", line 1858, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit_interp_jit.c", line 289, in portal_5 File "pypy_interpreter_pyopcode.c", line 3468, in handle_bytecode__AccessDirect_None File "pypy_interpreter_pyopcode.c", line 7995, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_pyopcode.c", line 21370, in EXEC_STMT__AccessDirect_None File "pypy_interpreter_pyframe.c", line 3185, in PyFrame_execute_frame File "rpython_jit_metainterp_warmspot.c", line 1858, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit_interp_jit.c", line 289, in portal_5 File "pypy_interpreter_pyopcode.c", line 3468, in handle_bytecode__AccessDirect_None File "pypy_interpreter_pyopcode.c", line 8067, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_pyopcode.c", line 25276, in IMPORT_NAME__AccessDirect_None File "pypy_interpreter_gateway.c", line 477, in BuiltinCode_funcrun_obj File "pypy_interpreter_gateway.c", line 2582, in BuiltinCode_handle_exception Fatal RPython error: OSError Aborted ``` This is probably caused by this code in module/imp/importing.py, inside load_part: ``` #!python try: if find_info: w_mod = load_module(space, w_modulename, find_info) [cut] finally: if find_info: stream = find_info.stream if stream: stream.close() ``` The stream.close() in the finally fails (because the fd has already been closed), but it's not caugth by anyone, and thus crashes the interpreter. Note that importing.py is full of stream.close() all around the place, so we probably need to think of a general solution for the problem. From issues-reply at bitbucket.org Mon Mar 23 19:03:15 2015 From: issues-reply at bitbucket.org (David MacIver) Date: Mon, 23 Mar 2015 18:03:15 -0000 Subject: [pypy-issue] Issue #2006: OperationalError when there are a lot of sqlite3 databases to close in GC (pypy/pypy) Message-ID: <20150323180315.14212.77651@app07.ash-private.bitbucket.org> New issue 2006: OperationalError when there are a lot of sqlite3 databases to close in GC https://bitbucket.org/pypy/pypy/issue/2006/operationalerror-when-there-are-a-lot-of David MacIver: In advance: I know you're going to tell me to please close my databases and I will do so. :-) I thought you'd probably want to know about this bug anyway. The following code when run produces a whole bunch of messages of the form Exception OperationalError: OperationalError(u'unable to close due to unfinalised statements',) in method __del__ of <__main__.SQLiteBackend object at 0x00000000024ee2a8> ignored ``` #!python import sqlite3 class SQLiteBackend(object): def __init__(self): self.connection = sqlite3.connect(":memory:") def close(self): self.connection.close() def __del__(self): self.close() def create_db_if_needed(self): conn = self.connection cursor = conn.cursor() try: cursor.execute(""" create table if not exists hypothesis_data_mapping( value text ) """) finally: cursor.close() conn.commit() if __name__ == '__main__': dbs = [] for i in xrange(1000): SQLiteBackend().create_db_if_needed() ``` Reducing the number of databases to ~100 it seems to no longer produce these errors. From issues-reply at bitbucket.org Tue Mar 24 17:56:27 2015 From: issues-reply at bitbucket.org (Robert Speer) Date: Tue, 24 Mar 2015 16:56:27 -0000 Subject: [pypy-issue] Issue #2007: pypy2: `codecs.charmap_decode` doesn't work on bytearrays (pypy/pypy) Message-ID: <20150324165627.17155.61564@app08.ash-private.bitbucket.org> New issue 2007: pypy2: `codecs.charmap_decode` doesn't work on bytearrays https://bitbucket.org/pypy/pypy/issue/2007/pypy2-codecscharmap_decode-doesnt-work-on Robert Speer: Unlike the CPython standard library, pypy2 2.5.0 does not allow `codecs.charmap_decode` to be used on bytearrays. This means that bytearrays cannot be decoded with some codecs. CPython 2.7.6: >>> bytearray('test').decode('cp1252') u'test' PyPy 2.5.0: >>>> bytearray('test').decode('cp1252') Traceback (most recent call last): File "", line 1, in File "/home/rspeer/src/pypy-2.5.0-linux64/lib-python/2.7/encodings/cp1252.py", line 15, in decode return codecs.charmap_decode(input,errors,decoding_table) TypeError: expected string, got bytearray object This causes the Unicode-fixing library [ftfy](https://github.com/LuminosoInsight/python-ftfy) to fail to import on PyPy2. From issues-reply at bitbucket.org Tue Mar 24 21:13:53 2015 From: issues-reply at bitbucket.org (Jeong YunWon) Date: Tue, 24 Mar 2015 20:13:53 -0000 Subject: [pypy-issue] Issue #2008: rpython None leads segfault. (pypy/pypy) Message-ID: <20150324201353.29161.99781@app03.ash-private.bitbucket.org> New issue 2008: rpython None leads segfault. https://bitbucket.org/pypy/pypy/issue/2008/rpython-none-leads-segfault Jeong YunWon: This is compiled and raising segfault. ``` def entry_point(argv): print len([None, ''][0]) return 0 def target(*args): return entry_point, None ``` Also no exception and segfault. ``` def entry_point(argv): try: print len([None, ''][0]) except Exception, e: print e return 0 ``` Is this intended and not checkable by annotator or a bug? From issues-reply at bitbucket.org Tue Mar 24 22:05:43 2015 From: issues-reply at bitbucket.org (gmludo) Date: Tue, 24 Mar 2015 21:05:43 -0000 Subject: [pypy-issue] Issue #2009: PyPy3: "yield from" doesn't return all values (pypy/pypy) Message-ID: <20150324210543.22921.74773@app13.ash-private.bitbucket.org> New issue 2009: PyPy3: "yield from" doesn't return all values https://bitbucket.org/pypy/pypy/issue/2009/pypy3-yield-from-doesnt-return-all-values gmludo: The script below prints "(1, 2)" with CPython 3.4.3, but "1" with pypy3.3 ``` #!python def f(): yield 3 return 1, 2 def g(): x = yield from f() print(x) list(g()) ``` From issues-reply at bitbucket.org Tue Mar 24 23:02:13 2015 From: issues-reply at bitbucket.org (Jacek Wielemborek) Date: Tue, 24 Mar 2015 22:02:13 -0000 Subject: [pypy-issue] Issue #2010: Memory leak while using bz2 + ElementTree.iterparse? (pypy/pypy) Message-ID: <20150324220213.17441.65019@app12.ash-private.bitbucket.org> New issue 2010: Memory leak while using bz2 + ElementTree.iterparse? https://bitbucket.org/pypy/pypy/issue/2010/memory-leak-while-using-bz2 Jacek Wielemborek: Tested using: pypy-2.5-linux_x86_64-portable/bin/pypy plwiki-20150219-pages-meta-history/plwiki-20150219-pages-meta-history1.xml.bz2. For code, see the attachment. From issues-reply at bitbucket.org Wed Mar 25 01:52:18 2015 From: issues-reply at bitbucket.org (Ronan Lamy) Date: Wed, 25 Mar 2015 00:52:18 -0000 Subject: [pypy-issue] Issue #2011: RPython: Better error message for obvious type errors (pypy/pypy) Message-ID: <20150325005218.11536.30482@app12.ash-private.bitbucket.org> New issue 2011: RPython: Better error message for obvious type errors https://bitbucket.org/pypy/pypy/issue/2011/rpython-better-error-message-for-obvious Ronan Lamy: Consider this code: ``` #!python def entry_point(argv): print len([0, 1][0]) return 0 def target(*args): return entry_point, None ``` Currently, translating it fails with ``` [translation:ERROR] MissingRTypeOperation: unimplemented operation: 'len' on [translation:ERROR] .. (targ:1)entry_point [translation:ERROR] .. block at 9 with 1 exits [translation:ERROR] .. v28 = len(v27) ``` which tends to confuse users. The problem, calling `len()` on an int, could easily be detected during annotation. If we raised an AnnotationError, we could have a much nicer error message, for instance: ``` [translation:ERROR] AnnotatorError: [translation:ERROR] [translation:ERROR] Object has no len() [translation:ERROR] [translation:ERROR] [translation:ERROR] v1 = len(v0) [translation:ERROR] [translation:ERROR] In : [translation:ERROR] Happened at file targ.py line 2 [translation:ERROR] [translation:ERROR] ==> print len([0, 1][0]) [translation:ERROR] [translation:ERROR] Known variable annotations: [translation:ERROR] v0 = SomeInteger(knowntype=int, nonneg=True, unsigned=False) [translation:ERROR] [translation:ERROR] Processing block: [translation:ERROR] block at 9 is a [translation:ERROR] in (targ:1)entry_point [translation:ERROR] containing the following operations: [translation:ERROR] v2 = newlist((0), (1)) [translation:ERROR] v0 = getitem(v2, (0)) [translation:ERROR] v1 = len(v0) [translation:ERROR] v3 = str(v1) [translation:ERROR] v4 = simple_call((function rpython_print_item), v3) [translation:ERROR] v5 = simple_call((function rpython_print_newline)) [translation:ERROR] --end-- ``` Note that `len()` is just an example, there are many similar cases, including those where the error message is the dreaded "Blocked block -- operation cannot succeed" instead of MissingRTypeOperation. From issues-reply at bitbucket.org Thu Mar 26 13:00:59 2015 From: issues-reply at bitbucket.org (Michael Kesper) Date: Thu, 26 Mar 2015 12:00:59 -0000 Subject: [pypy-issue] Issue #2012: PyPy3 - Please include pip (pypy/pypy) Message-ID: <20150326120059.3024.54086@app11.ash-private.bitbucket.org> New issue 2012: PyPy3 - Please include pip https://bitbucket.org/pypy/pypy/issue/2012/pypy3-please-include-pip Michael Kesper: Integration of pip was an enormous step regarding usability of Python altogether. Please include it also with PyPy3. This should also mitigate https://bitbucket.org/pypy/pypy/issue/1696/can-not-install-pip-with-get-pippy From issues-reply at bitbucket.org Fri Mar 27 12:28:36 2015 From: issues-reply at bitbucket.org (Cory Benfield) Date: Fri, 27 Mar 2015 11:28:36 -0000 Subject: [pypy-issue] Issue #2013: PyPy 2.5.1 missing some SSL constants (pypy/pypy) Message-ID: <20150327112836.4556.70209@app01.ash-private.bitbucket.org> New issue 2013: PyPy 2.5.1 missing some SSL constants https://bitbucket.org/pypy/pypy/issue/2013/pypy-251-missing-some-ssl-constants Cory Benfield: Per [this gist](https://gist.github.com/Lukasa/c5c304a4c355d6f49035): ```python Python 2.7.9 (9c4588d731b7, Mar 23 2015, 20:00:36) [PyPy 2.5.1 with MSC v.1500 32 bit] on win32 Type "help", "copyright", "credits" or "license" for more information. >>>> import ssl >>>> ssl.OPENSSL_VERSION 'OpenSSL 1.0.1i 6 Aug 2014' >>>> ssl.PROTOCOL_TLSv1_2 Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'PROTOCOL_TLSv1_2' ``` This is probably caused by the backport of the 2.7.9 SSL module, which newly exposed this constant (along with some others). I recommend checking all the constants in [this document](https://docs.python.org/2/library/ssl.html) that were added in 2.7.9 to see if they got left out. From issues-reply at bitbucket.org Sun Mar 29 17:05:17 2015 From: issues-reply at bitbucket.org (Alex Gaynor) Date: Sun, 29 Mar 2015 15:05:17 -0000 Subject: [pypy-issue] Issue #2014: PyLong_FromUnicode is missing from cpyext (pypy/pypy) Message-ID: <20150329150517.9726.76932@app08.ash-private.bitbucket.org> New issue 2014: PyLong_FromUnicode is missing from cpyext https://bitbucket.org/pypy/pypy/issue/2014/pylong_fromunicode-is-missing-from-cpyext Alex Gaynor: