From issues-reply at bitbucket.org Sun Jan 1 11:52:18 2017 From: issues-reply at bitbucket.org (Armin Rigo) Date: Sun, 01 Jan 2017 16:52:18 -0000 Subject: [pypy-issue] Issue #2460: _cffi_src/openssl/callbacks.py uses the CPython C API (pypy/pypy) Message-ID: <20170101165218.14097.47108@celery-worker-107.ash1.bb-inf.net> New issue 2460: _cffi_src/openssl/callbacks.py uses the CPython C API https://bitbucket.org/pypy/pypy/issues/2460/_cffi_src-openssl-callbackspy-uses-the Armin Rigo: ``_cffi_src/openssl/callbacks.py`` uses some functions from the CPython C API: PyMem_New, PyThread_acquire_lock(), and so on. Nothing that handles PyObjects. Still, it makes ``_cffi_ssl`` fail to import on a PyPy that was translated without ``cpyext``. Should be fixed. From issues-reply at bitbucket.org Tue Jan 3 04:30:52 2017 From: issues-reply at bitbucket.org (Dmitry Kravkov) Date: Tue, 03 Jan 2017 09:30:52 -0000 Subject: [pypy-issue] Issue #2461: segfault in libz.so.1.2.3 (pypy/pypy) Message-ID: <20170103093052.19345.39882@celery-worker-107.ash1.bb-inf.net> New issue 2461: segfault in libz.so.1.2.3 https://bitbucket.org/pypy/pypy/issues/2461/segfault-in-libzso123 Dmitry Kravkov: kernel:: segfault at 7f67f0709000 ip 00007f680cca1866 sp 00007fff512313a8 error 4 in libz.so.1.2.3 (deleted)[7f680cc9f000+15000] Python 2.6.6 (r266:84292, Nov 22 2013, 12:16:22) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2 From issues-reply at bitbucket.org Wed Jan 4 05:00:37 2017 From: issues-reply at bitbucket.org (Unknown) Date: Wed, 04 Jan 2017 10:00:37 -0000 Subject: [pypy-issue] Issue #2462: `__init__` inherited from object incorrectly considered method by `inspect` (pypy/pypy) Message-ID: <20170104100037.18451.56523@celery-worker-106.ash1.bb-inf.net> New issue 2462: `__init__` inherited from object incorrectly considered method by `inspect` https://bitbucket.org/pypy/pypy/issues/2462/__init__-inherited-from-object-incorrectly Unknown: To reproduce: ``` #!python import inspect class C(object): pass assert not inspect.ismethod(C.__init__) assert not inspect.isfunction(C.__init__) ``` The above succeeds with Python 2 and Python 3 (and with Jython and IronPython for that matter) but fails both with PyPy2 and PyPy3. This is a problem for code that uses introspection to see what arguments a class accepts. With PyPy it looks as if this `__init__` would accept arguments because it is method/function (depending on are we on PyPy2 or PyPy3, similarly as in Python itself) and `inspect.getargspec(C.__init__)` returns this: ArgSpec(args=['obj'], varargs='args', keywords='keywords', defaults=None) With Python 2 and Python 3 what you get from `inspect.getargspec` depends on the version (Python 2 raises `TypeError` and Python 3 returns similar result as PyPy), but that doesn't matter because neither of them consider this `__init__` a method or a function in the first place. From issues-reply at bitbucket.org Thu Jan 5 02:39:03 2017 From: issues-reply at bitbucket.org (xiaoyao) Date: Thu, 05 Jan 2017 07:39:03 -0000 Subject: [pypy-issue] Issue #2463: windows(win7) pypy5.6 time.clock CRASH (pypy/pypy) Message-ID: <20170105073903.34841.27646@celery-worker-108.ash1.bb-inf.net> New issue 2463: windows(win7) pypy5.6 time.clock CRASH https://bitbucket.org/pypy/pypy/issues/2463/windows-win7-pypy56-timeclock-crash xiaoyao: #begin while True: import time time.clock() #it crashed on windows(win7) pypy5.6 #the same code runs well on windows(win7) python2.7(32bit) Responsible: arigo From issues-reply at bitbucket.org Wed Jan 11 08:41:17 2017 From: issues-reply at bitbucket.org (Mike McKerns) Date: Wed, 11 Jan 2017 13:41:17 -0000 Subject: [pypy-issue] Issue #2464: getset_descriptor cannot access `__objclass__` (pypy/pypy) Message-ID: <20170111134117.7439.86594@celery-worker-105.ash1.bb-inf.net> New issue 2464: getset_descriptor cannot access `__objclass__` https://bitbucket.org/pypy/pypy/issues/2464/getset_descriptor-cannot-access Mike McKerns: It looks like a getset_descriptor has an `__objclass__` (as seen with `dir`), but it's not available as an attribute. `__objclass__` is very useful in maintaining a pointer to the descriptor's class. For example, given an `__objclass__` attribute, one could pickle a descriptor... and thus make a broader class of objects available to multiprocessing, parallel, and distributed computing. (I'm the `dill` author, and this is a huge blocker for people using `pypy` + `dill`) ``` #!python >>>> class _d(object): .... def _method(self): .... pass .... >>>> d = _d.__dict__['__dict__'] >>>> d >>>> dir(d) ['__class__', '__delattr__', '__delete__', '__doc__', '__format__', '__get__', '__getattribute__', '__hash__', '__init__', '__name__', '__new__', '__objclass__', '__reduce__', '__reduce_ex__', '__repr__', '__set__', '__setattr__', '__str__', '__subclasshook__'] >>>> d.__objclass__ Traceback (most recent call last): File "", line 1, in AttributeError: generic property has no __objclass__ ``` Can the `__objclass__` attribute be made available as a pointer to the descriptor's class? It seems like a bug that `__objclass__` is missing. From issues-reply at bitbucket.org Sat Jan 14 04:36:05 2017 From: issues-reply at bitbucket.org (urimend) Date: Sat, 14 Jan 2017 09:36:05 -0000 Subject: [pypy-issue] Issue #2465: AssertionError in _compute_hint_frame_locations_from_descr (pypy/pypy) Message-ID: <20170114093605.7355.20464@celery-worker-108.ash1.bb-inf.net> New issue 2465: AssertionError in _compute_hint_frame_locations_from_descr https://bitbucket.org/pypy/pypy/issues/2465/assertionerror-in urimend: Pypy crashes with the following traceback. RPython traceback: File "rpython_jit_metainterp_13.c", line 54720, in send_loop_to_backend File "rpython_jit_backend_x86.c", line 2328, in Assembler386_assemble_loop File "rpython_jit_backend_x86.c", line 7217, in Assembler386__assemble File "rpython_jit_backend_x86.c", line 13625, in RegAlloc_walk_operations File "rpython_jit_backend_x86.c", line 28923, in RegAlloc__compute_hint_frame_locations_from_desc Fatal RPython error: AssertionError From issues-reply at bitbucket.org Tue Jan 17 05:54:16 2017 From: issues-reply at bitbucket.org (Wang Xuancong) Date: Tue, 17 Jan 2017 10:54:16 -0000 Subject: [pypy-issue] Issue #2466: request for the capability of updating local variable list using locals().update() (pypy/pypy) Message-ID: <20170117105416.26615.78709@celery-worker-105.ash1.bb-inf.net> New issue 2466: request for the capability of updating local variable list using locals().update() https://bitbucket.org/pypy/pypy/issues/2466/request-for-the-capability-of-updating Wang Xuancong: The ability of updating local variable name list becomes important and useful when we talk about meta-programming. For example, we can use the following line to save and load all local variables instead of importing json and writing down every variable we want to save/load: ``` print >>open('model.txt','w'), locals() locals().update(eval(open('model.txt').read())) ``` This functionality is particularly useful in designing neural networks using Tensorflow/Theano/etc. We can snapshot/restore all local variables so that we can continue to work on from somewhere else. However, due to interpreter optimization, python is not designed to do this: [https://docs.python.org/2/library/functions.html#locals](Link URL), the same holds for PyPy: ``` >>>> def f1(): .... locals().update({'aa':5}) .... print aa .... >>>> f1() Traceback (most recent call last): File "", line 1, in File "", line 3, in f1 NameError: global name 'aa' is not defined ``` Since PyPy has built-in JIT, it does not need to be too concerned about interpreter optimization. Thus, I hope this functionality can be implemented in PyPy as an advantage over Python. From issues-reply at bitbucket.org Tue Jan 17 12:31:32 2017 From: issues-reply at bitbucket.org (Tobias Oberstein) Date: Tue, 17 Jan 2017 17:31:32 -0000 Subject: [pypy-issue] Issue #2467: cpppypy fails to build on gcc 5 and clang (pypy/pypy) Message-ID: <20170117173132.29113.63908@celery-worker-108.ash1.bb-inf.net> New issue 2467: cpppypy fails to build on gcc 5 and clang https://bitbucket.org/pypy/pypy/issues/2467/cpppypy-fails-to-build-on-gcc-5-and-clang Tobias Oberstein: Not 100% positive if this is the right place to file issues for cpppypy (pls redirect me if not). I am following http://doc.pypy.org/en/latest/cppyy.html#installation to build cpppypy on Ubuntu 16.04 LTS (desktop) using pypy-5.6 (portable). This distro uses a gcc 5 toolchain by default, and the build fails with "Found GCC compiler with new ABI. Cling does not support the GCC 5 ABI yet". When using clang (pls see here https://github.com/oberstet/scratchbox/blob/master/cpp/capnproto/test1/Makefile#L5), the build fails with this https://gist.github.com/oberstet/1771d9142cf566c5a877de0df5500899 -- Right now I am building with gcc 4.9, which so far seems to work (https://github.com/oberstet/scratchbox/blob/master/cpp/capnproto/test1/Makefile#L17). Goal: ultimately, I want to get captnproto working using C++ generated stubs auto exposed with cpppypy in pypy. From issues-reply at bitbucket.org Tue Jan 17 21:15:02 2017 From: issues-reply at bitbucket.org (Wang Xuancong) Date: Wed, 18 Jan 2017 02:15:02 -0000 Subject: [pypy-issue] Issue #2468: Should make header files compatible (pypy/pypy) Message-ID: <20170118021502.20297.64581@celery-worker-106.ash1.bb-inf.net> New issue 2468: Should make header files compatible https://bitbucket.org/pypy/pypy/issues/2468/should-make-header-files-compatible Wang Xuancong: Dear PyPy developers, When I run "pypy -m pip install --upgrade tensorflow-*.whl", I typically get the following error: ``` tensorflow-0.11.0-cp27-none-linux_x86_64.whl is not a supported wheel on this platform. ``` The reason is because some of the dynamic libraries of tensorflow (such as _pywrap_tensorflow.so) is compiled and linked against Python headers instead of PyPy headers. If you really want PyPy to have maximal compatibility with Python, I suggest you to make PyPy to be able to import *.so on both Python headers and PyPy headers, maybe with a sacrifice of performance for *.so with Python headers. Otherwise, a lot of pip packages for Python cannot be installed under PyPy, which is quite a disappointment. From issues-reply at bitbucket.org Wed Jan 18 17:14:07 2017 From: issues-reply at bitbucket.org (Spenser Bauman) Date: Wed, 18 Jan 2017 22:14:07 -0000 Subject: [pypy-issue] Issue #2469: Array out of bounds access in RegAlloc.consider_jump (pypy/pypy) Message-ID: <20170118221407.7918.22881@celery-worker-108.ash1.bb-inf.net> New issue 2469: Array out of bounds access in RegAlloc.consider_jump https://bitbucket.org/pypy/pypy/issues/2469/array-out-of-bounds-access-in Spenser Bauman: Possibly related to Issue #2465. The JIT backend segfaults when the `retrace_limit > 1`. The error occurs in `RegAlloc.consider_jump` for the x86 backend. The underlying problems seems to be that `op.numargs() > len(arglocs)`, so the jump operations is receiving more arguments that expected. Currently, I only know how to produce this error with Pycket, but I can attempt reproduction in PyPy if it becomes an issue. Full stack trace: #0 pypy_g_RegAlloc_consider_jump (l_self_6628=0x7ffff7128a40, l_op_592=0x7ffff712dd78) at rpython_jit_backend_x86.c:36635 #1 0x0000000000849e13 in pypy_g_RegAlloc_walk_operations (l_self_6591=l_self_6591 at entry=0x7ffff7128a40, l_inputargs_31=0x7ffff71039c0, l_operations_41=0x7ffff7128c28) at rpython_jit_backend_x86.c:12181 #2 0x000000000084a816 in pypy_g_Assembler386__assemble (l_self_6575=l_self_6575 at entry=0x115ad60 , l_regalloc_5=l_regalloc_5 at entry=0x7ffff7128a40, l_inputargs_30=, l_inputargs_30 at entry=0x7ffff71039c0, l_operations_39=, l_operations_39 at entry=0x7ffff7128c28) at rpython_jit_backend_x86.c:6148 #3 0x00000000008634fc in pypy_g_Assembler386_assemble_loop (l_self_6570=0x115ad60 , l_jd_id_4=l_jd_id_4 at entry=0, l_unique_id_5=l_unique_id_5 at entry=0, l_logger_3=0x1190800 , l_loopname_1=l_loopname_1 at entry=0x11933e0 , l_inputargs_28=l_inputargs_28 at entry=0x7ffff71039c0, l_operations_34=0x7ffff71282c8, l_looptoken_15=, l_log_4=0) at rpython_jit_backend_x86.c:1746 #4 0x0000000000ab3487 in pypy_g_do_compile_loop (l_jd_id_5=0, l_unique_id_9=0, l_inputargs_45=0x7ffff71039c0, l_operations_51=0x7ffff71282c8, l_looptoken_23=l_looptoken_23 at entry=0x7ffff71285b0, l_log_8=l_log_8 at entry=0, l_name_141=0x11933e0 , l_memo_11=0x7ffff70bb070) at rpython_jit_metainterp_5.c:22228 #5 0x0000000000ab3a3d in pypy_g_send_loop_to_backend (l_greenkey_224=, l_jitdriver_sd_182=, l_loop_20=l_loop_20 at entry=0x7ffff7128580, l_type_39=0x1165ae0 , l_orig_inpargs_0=l_orig_inpargs_0 at entry=0x7ffff7102a90, l_memo_30=0x7ffff70bb070) at rpython_jit_metainterp_5.c:19764 #6 0x0000000000ab4003 in pypy_g_ResumeFromInterpDescr_compile_and_attach (l_self_4114=l_self_4114 at entry=0x7ffff70bcd38, l_metainterp_446=l_metainterp_446 at entry=0x7ffff70bae18, l_new_loop_2=l_new_loop_2 at entry=0x7ffff7128580, l_orig_inputargs_2=l_orig_inputargs_2 at entry=0x7ffff7102a90) at rpython_jit_metainterp_5.c:14483 #7 0x0000000000a8be6f in pypy_g_compile_trace (l_metainterp_437=l_metainterp_437 at entry=0x7ffff70bae18, l_resumekey_2=l_resumekey_2 at entry=0x7ffff70bcd38, l_runtime_boxes_6=, l_runtime_boxes_6 at entry=0x7ffff7102a58) at rpython_jit_metainterp_4.c:53770 #8 0x0000000000a9d098 in pypy_g_MetaInterp_compile_trace (l_self_7943=l_self_7943 at entry=0x7ffff70bae18, l_live_arg_boxes_4=l_live_arg_boxes_4 at entry=0x7ffff7102490) at rpython_jit_metainterp_4.c:4293 #9 0x0000000000a28231 in pypy_g_MetaInterp_reached_loop_header (l_self_7822=0x7ffff70bae18, l_greenboxes_7=, l_greenboxes_7 at entry=0x7ffff7102208, l_redboxes_5=, l_redboxes_5 at entry=0x7ffff7102240) at rpython_jit_metainterp_3.c:21107 #10 0x0000000000a04834 in pypy_g_MIFrame_opimpl_jit_merge_point (l_self_7508=0x7ffff70bb310, l_jdindex_7=, l_greenboxes_5=0x7ffff7102208, l_jcposition_1=11, l_redboxes_3=0x7ffff7102240, l_orgpc_16=4) at rpython_jit_metainterp_2.c:35241 #11 0x00000000009a8277 in pypy_g_MIFrame_run_one_step (l_self_7237=0x7ffff70bb310) at rpython_jit_metainterp_1.c:45002 #12 0x00000000009c8b5b in pypy_g_MetaInterp__interpret (l_self_7158=l_self_7158 at entry=0x7ffff70bae18) at rpython_jit_metainterp_1.c:26801 #13 0x00000000009c8c59 in pypy_g_MetaInterp_interpret (l_self_2197=l_self_2197 at entry=0x7ffff70bae18) at rpython_jit_metainterp_1.c:18961 #14 0x00000000009c95cb in pypy_g_MetaInterp__compile_and_run_once (l_self_7105=0x7ffff70bae18, l_original_boxes_102=0x7ffff70bb210) at rpython_jit_metainterp_1.c:14280 #15 0x00000000009808c6 in pypy_g_compile_and_run_once___rpython_jit_metainterp_ji_1 (l_self_7063=, l_v599013=, l_v599013 at entry=0x1f013c8, l_v599014=, l_v599014 at entry=0x1f135a0, l_v599015=, l_v599015 at entry=0x7ffff70bade0, l_v599016=) at rpython_jit_metainterp.c:61183 #16 0x0000000000980c42 in pypy_g_bound_reached__star_4 (l_hash_2232=l_hash_2232 at entry=13857789584669487964, l_cell_131=0x7ffff70bb0c8, l_cell_131 at entry=0x0, l_stararg0_5139=l_stararg0_5139 at entry=0x1f013c8, l_stararg1_3207=l_stararg1_3207 at entry=0x1f135a0, l_stararg2_2440=l_stararg2_2440 at entry=0x7ffff70bade0, l_stararg3_1240=, l_stararg3_1240 at entry=0x7ffff70bac60) at rpython_jit_metainterp.c:34522 #17 0x00000000009811e4 in pypy_g_maybe_compile_and_run__star_4 (l_increment_threshold_21=, l_v580039=l_v580039 at entry=0x1f013c8, l_v580040=l_v580040 at entry=0x1f135a0, l_v580041=, l_v580041 at entry=0x7ffff70bade0, l_v580042=, l_v580042 at entry=0x7ffff70bac60) at rpython_jit_metainterp.c:9646 #18 0x000000000056e3d9 in pypy_g_portal_1 (l_ast_112=0x1f013c8, l_ast_112 at entry=0x1fd1100, l_ast_111=, l_ast_111 at entry=0x1db8460, l_env_557=0x7ffff70bade0, l_env_557 at entry=0x7ffff70baaa0, l_cont_333=) at pycket_interpreter.c:59608 #19 0x000000000097fe5b in pypy_g_handle_jitexception_1 (l_e_21=) at rpython_jit_metainterp.c:9120 #20 0x0000000000981998 in pypy_g_ll_portal_runner__pycket_AST_ASTPtr_pycket_AST_A (l_v577398=, l_v577398 at entry=0x1f70d20, l_v577399=, l_v577399 at entry=0x1f70d20, l_v577400=, l_v577401=) at rpython_jit_metainterp.c:2670 #21 0x000000000054e47b in pypy_g_inner_interpret_two_state (l_cont_47=, l_env_154=, l_ast_36=0x1f70d20) at pycket_interpreter.c:46866 #22 pypy_g_interpret_one (l_ast_87=l_ast_87 at entry=0x1f70d20, l_env_28=) at pycket_interpreter.c:17691 #23 0x000000000054ea3d in pypy_g_Module__interpret_mod (l_self_5519=l_self_5519 at entry=0x1bfe240, l_env_522=) at pycket_interpreter.c:1190 #24 0x000000000054f544 in pypy_g_interpret_module (l_m_8=0x1bfe240, l_env_521=, l_env_521 at entry=0x1e88660) at pycket_interpreter.c:66 #25 0x00000000004dc483 in pypy_g_actual_entry (l_argv_2=) at pycket_entry_point.c:1430 #26 0x00000000004dd0eb in pypy_g_entry_point (l_argv_5=) at pycket_entry_point.c:36 #27 0x0000000000d3a900 in pypy_g_entrypoint_wrapper (l_argc_2=l_argc_2 at entry=5, l_argv_7=l_argv_7 at entry=0x7fffffffdf48) at rpython_translator_c.c:60 #28 0x0000000000d3b555 in pypy_main_function (argc=5, argv=0x7fffffffdf48) at entrypoint.c:97 #29 0x00007ffff7300830 in __libc_start_main (main=0x402a40
, argc=5, argv=0x7fffffffdf48, init=, fini=, rtld_fini=, stack_end=0x7fffffffdf38) at ../csu/libc-start.c:291 #30 0x0000000000402a79 in _start () From issues-reply at bitbucket.org Thu Jan 19 02:46:35 2017 From: issues-reply at bitbucket.org (longriver) Date: Thu, 19 Jan 2017 07:46:35 -0000 Subject: [pypy-issue] Issue #2470: Random crash when using gevent with some IO pressure (pypy/pypy) Message-ID: <20170119074635.13610.46500@celery-worker-101.ash1.bb-inf.net> New issue 2470: Random crash when using gevent with some IO pressure https://bitbucket.org/pypy/pypy/issues/2470/random-crash-when-using-gevent-with-some longriver: I found would crash when using the lasted pypy2 version (pypy2-5.6.0 + gevent-1.2.1), with --jit off or cpython do not crash. running environment: linux kernel 3.10.94, gcc 4.8.5, libffi.so.6.0.1, Intel Xeon E312xx (Sandy Bridge) 64 bits pypy2-5.3, pypy2-5.4 will crash too (gevent-1.0, gevent-1.1), it like the issue #2132. ``` #!python Exception KeyError: KeyError(44049520L,) in threading._shutdown() ignored mem.c: 10517 mallocs left (use PYPY_ALLOC=1 to see the list) RPython traceback: File "pypy_goal.c", line 1089, in entry_point File "rpython_rlib_rvmprof.c", line 209, in execute_frame_rvmprof__star_3 File "pypy_interpreter_1.c", line 57810, in execute_frame File "rpython_jit_metainterp.c", line 38209, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit.c", line 183, in portal_39 File "pypy_interpreter_3.c", line 415, in handle_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 7581, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 30561, in call_function__AccessDirect_None File "rpython_rlib_rvmprof.c", line 209, in execute_frame_rvmprof__star_3 File "pypy_interpreter_1.c", line 57810, in execute_frame File "rpython_jit_metainterp.c", line 38209, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit.c", line 183, in portal_39 File "pypy_interpreter_3.c", line 415, in handle_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 7617, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 30561, in call_function__AccessDirect_None File "rpython_rlib_rvmprof.c", line 209, in execute_frame_rvmprof__star_3 File "pypy_interpreter_1.c", line 57810, in execute_frame File "rpython_jit_metainterp.c", line 38209, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit.c", line 183, in portal_39 File "pypy_interpreter_3.c", line 415, in handle_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 7664, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 30561, in call_function__AccessDirect_None File "rpython_rlib_rvmprof.c", line 209, in execute_frame_rvmprof__star_3 File "pypy_interpreter_1.c", line 57810, in execute_frame File "rpython_jit_metainterp.c", line 38209, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit.c", line 183, in portal_39 File "pypy_interpreter_3.c", line 415, in handle_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 8257, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 24741, in EXEC_STMT__AccessDirect_None File "rpython_rlib_rvmprof.c", line 209, in execute_frame_rvmprof__star_3 File "pypy_interpreter_1.c", line 57810, in execute_frame File "rpython_jit_metainterp.c", line 38209, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit.c", line 183, in portal_39 File "pypy_interpreter_3.c", line 415, in handle_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 7545, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 31179, in CALL_FUNCTION__AccessDirect_None File "rpython_rlib_rvmprof.c", line 209, in execute_frame_rvmprof__star_3 File "pypy_interpreter_1.c", line 57810, in execute_frame File "rpython_jit_metainterp.c", line 38209, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit.c", line 183, in portal_39 File "pypy_interpreter_3.c", line 415, in handle_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 7686, in dispatch_bytecode__AccessDirect_None File "pypy_objspace_std_8.c", line 25164, in CALL_METHOD__AccessDirect_star_1 File "rpython_rlib_rvmprof.c", line 209, in execute_frame_rvmprof__star_3 File "pypy_interpreter_1.c", line 57810, in execute_frame File "rpython_jit_metainterp.c", line 38209, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit.c", line 183, in portal_39 File "pypy_interpreter_3.c", line 415, in handle_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 7545, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 31179, in CALL_FUNCTION__AccessDirect_None File "rpython_rlib_rvmprof.c", line 209, in execute_frame_rvmprof__star_3 File "pypy_interpreter_1.c", line 57810, in execute_frame File "rpython_jit_metainterp.c", line 38209, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit.c", line 183, in portal_39 File "pypy_interpreter_3.c", line 415, in handle_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 7686, in dispatch_bytecode__AccessDirect_None File "pypy_objspace_std_8.c", line 25164, in CALL_METHOD__AccessDirect_star_1 File "rpython_rlib_rvmprof.c", line 209, in execute_frame_rvmprof__star_3 File "pypy_interpreter_1.c", line 57810, in execute_frame File "rpython_jit_metainterp.c", line 38209, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit.c", line 183, in portal_39 File "pypy_interpreter_3.c", line 415, in handle_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 7686, in dispatch_bytecode__AccessDirect_None File "pypy_objspace_std_8.c", line 25164, in CALL_METHOD__AccessDirect_star_1 File "rpython_rlib_rvmprof.c", line 209, in execute_frame_rvmprof__star_3 File "pypy_interpreter_1.c", line 57810, in execute_frame File "rpython_jit_metainterp.c", line 38209, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit.c", line 183, in portal_39 File "pypy_interpreter_3.c", line 415, in handle_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 7545, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 30561, in call_function__AccessDirect_None File "rpython_rlib_rvmprof.c", line 209, in execute_frame_rvmprof__star_3 File "pypy_interpreter_1.c", line 57810, in execute_frame File "rpython_jit_metainterp.c", line 38209, in ll_portal_runner__Unsigned_Bool_pypy_interpreter File "pypy_module_pypyjit.c", line 183, in portal_39 File "pypy_interpreter_3.c", line 415, in handle_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 7545, in dispatch_bytecode__AccessDirect_None File "pypy_interpreter_3.c", line 31179, in CALL_FUNCTION__AccessDirect_None File "pypy_interpreter.c", line 39456, in BuiltinCodePassThroughArguments1_funcrun_obj File "pypy_interpreter.c", line 44227, in BuiltinCode_handle_exception Fatal RPython error: FrontendTagOverflow ./test.sh: line 7: 12779 aborted (core dump)PYTHONPATH=cevapp python cevapp/main.py --opttype=cev_fix --area_id=1 ``` From issues-reply at bitbucket.org Thu Jan 19 02:47:19 2017 From: issues-reply at bitbucket.org (longriver) Date: Thu, 19 Jan 2017 07:47:19 -0000 Subject: [pypy-issue] [Bitbucket] Issue #2470: Random crash when using gevent with some IO pressure (pypy/pypy) In-Reply-To: References: Message-ID: --- you can reply above this line --- Issue 2470: Random crash when using gevent with some IO pressure https://bitbucket.org/pypy/pypy/issues/2470/random-crash-when-using-gevent-with-some longriver: Changes: responsible: nothing -> pypy-issue component: nothing -> PyPy (running Python 2.7) -- Unwatch this issue to stop receiving email updates: https://bitbucket.org/api/1.0/repositories/pypy/pypy/issue/2470/unwatch/pypy-issue/e1044d1a59b5b796d254dae6600369929fed1e5c/ From issues-reply at bitbucket.org Thu Jan 19 03:55:24 2017 From: issues-reply at bitbucket.org (Armin Rigo) Date: Thu, 19 Jan 2017 08:55:24 -0000 Subject: [pypy-issue] [Bitbucket] Issue #2470: Random crash when using gevent with some IO pressure (pypy/pypy) In-Reply-To: References: Message-ID: --- you can reply above this line --- Issue 2470: Random crash when using gevent with some IO pressure https://bitbucket.org/pypy/pypy/issues/2470/random-crash-when-using-gevent-with-some Armin Rigo: Thanks for the issue! I may have fixed the problem in f3161216aeed, but I have no way to be sure. Please report if you still get a similar error with a newer PyPy (try http://buildbot.pypy.org/nightly/trunk/ from tomorrow 20th Jan, or later). -- Unwatch this issue to stop receiving email updates: https://bitbucket.org/api/1.0/repositories/pypy/pypy/issue/2470/unwatch/pypy-issue/e1044d1a59b5b796d254dae6600369929fed1e5c/ From issues-reply at bitbucket.org Thu Jan 19 03:56:02 2017 From: issues-reply at bitbucket.org (Armin Rigo) Date: Thu, 19 Jan 2017 08:56:02 -0000 Subject: [pypy-issue] [Bitbucket] Issue #2470: Random crash when using gevent with some IO pressure (pypy/pypy) In-Reply-To: References: Message-ID: --- you can reply above this line --- Issue 2470: Random crash when using gevent with some IO pressure https://bitbucket.org/pypy/pypy/issues/2470/random-crash-when-using-gevent-with-some Armin Rigo: Changes: status: new -> resolved -- Unwatch this issue to stop receiving email updates: https://bitbucket.org/api/1.0/repositories/pypy/pypy/issue/2470/unwatch/pypy-issue/e1044d1a59b5b796d254dae6600369929fed1e5c/ From issues-reply at bitbucket.org Thu Jan 19 06:15:51 2017 From: issues-reply at bitbucket.org (longriver) Date: Thu, 19 Jan 2017 11:15:51 -0000 Subject: [pypy-issue] [Bitbucket] Issue #2470: Random crash when using gevent with some IO pressure (pypy/pypy) In-Reply-To: References: Message-ID: --- you can reply above this line --- Issue 2470: Random crash when using gevent with some IO pressure https://bitbucket.org/pypy/pypy/issues/2470/random-crash-when-using-gevent-with-some longriver: Thanks very much, I will try on tomorrow. -- Unwatch this issue to stop receiving email updates: https://bitbucket.org/api/1.0/repositories/pypy/pypy/issue/2470/unwatch/pypy-issue/e1044d1a59b5b796d254dae6600369929fed1e5c/ From issues-reply at bitbucket.org Thu Jan 19 09:49:17 2017 From: issues-reply at bitbucket.org (Armin Rigo) Date: Thu, 19 Jan 2017 14:49:17 -0000 Subject: [pypy-issue] [Bitbucket] Issue #2470: Random crash when using gevent with some IO pressure (pypy/pypy) In-Reply-To: References: Message-ID: --- you can reply above this line --- Issue 2470: Random crash when using gevent with some IO pressure https://bitbucket.org/pypy/pypy/issues/2470/random-crash-when-using-gevent-with-some Armin Rigo: Just built b1c862cb933e, it also has this fix. (I also fixed the link in my previous message, the hash was wrong.) -- Unwatch this issue to stop receiving email updates: https://bitbucket.org/api/1.0/repositories/pypy/pypy/issue/2470/unwatch/pypy-issue/e1044d1a59b5b796d254dae6600369929fed1e5c/ From issues-reply at bitbucket.org Fri Jan 20 06:39:10 2017 From: issues-reply at bitbucket.org (longriver) Date: Fri, 20 Jan 2017 11:39:10 -0000 Subject: [pypy-issue] [Bitbucket] Issue #2470: Random crash when using gevent with some IO pressure (pypy/pypy) In-Reply-To: References: Message-ID: --- you can reply above this line --- Issue 2470: Random crash when using gevent with some IO pressure https://bitbucket.org/pypy/pypy/issues/2470/random-crash-when-using-gevent-with-some longriver: I tested the [b1c862cb933e](https://bitbucket.org/pypy/pypy/commits/b1c862cb933e) version, no crash now, that is greate. To Armin Rigo, thank you very much. -- Unwatch this issue to stop receiving email updates: https://bitbucket.org/api/1.0/repositories/pypy/pypy/issue/2470/unwatch/pypy-issue/e1044d1a59b5b796d254dae6600369929fed1e5c/ From issues-reply at bitbucket.org Sun Jan 22 02:18:35 2017 From: issues-reply at bitbucket.org (longriver) Date: Sun, 22 Jan 2017 07:18:35 -0000 Subject: [pypy-issue] [Bitbucket] Issue #2470: Random crash when using gevent with some IO pressure (pypy/pypy) In-Reply-To: References: Message-ID: --- you can reply above this line --- Issue 2470: Random crash when using gevent with some IO pressure https://bitbucket.org/pypy/pypy/issues/2470/random-crash-when-using-gevent-with-some longriver: core dump?cannot find gc roots! -- Unwatch this issue to stop receiving email updates: https://bitbucket.org/api/1.0/repositories/pypy/pypy/issue/2470/unwatch/pypy-issue/e1044d1a59b5b796d254dae6600369929fed1e5c/ From issues-reply at bitbucket.org Sun Jan 22 02:29:38 2017 From: issues-reply at bitbucket.org (longriver) Date: Sun, 22 Jan 2017 07:29:38 -0000 Subject: [pypy-issue] [Bitbucket] Issue #2470: Random crash when using gevent with some IO pressure (pypy/pypy) In-Reply-To: References: Message-ID: --- you can reply above this line --- Issue 2470: Random crash when using gevent with some IO pressure https://bitbucket.org/pypy/pypy/issues/2470/random-crash-when-using-gevent-with-some longriver: Crash occurred when running another program using the pypy2-5.7-alpha version, the core info is different(see the core.tgz attachement), this is another bug? or my environment problem? linux kernel 2.6.32.57, Intel(R) Xeon(R) CPU E5-2630 64bits cpu ``` #!python Core was generated by `python -m main --name=mvp_count --appid=3'. Program terminated with signal 6, Aborted. #0 0x00007f12681e9625 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-7.el6_0.x86_64 expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.149.tl1.6.x86_64 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6_2.1.x86_64 libcom_err-1.41.12-11.el6.x86_64 libffi-3.0.5-3.2.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64 libuuid-2.17.2-12.5.tl1.x86_64 ncurses-libs-5.7-3.20090208.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.1e-42.tl1.6.x86_64 zlib-1.2.3-27.el6.x86_64 (gdb) bt #0 0x00007f12681e9625 in raise () from /lib64/libc.so.6 #1 0x00007f12681eae05 in abort () from /lib64/libc.so.6 #2 0x00007f126ac803e4 in ?? () from /data/tgp/pallas/pypy2-5.7.0-alpha0-tlinux1.2/bin/libpypy-c.so #3 0x00007f126aceb683 in ?? () from /data/tgp/pallas/pypy2-5.7.0-alpha0-tlinux1.2/bin/libpypy-c.so #4 0x00007f126ac760f8 in ?? () from /data/tgp/pallas/pypy2-5.7.0-alpha0-tlinux1.2/bin/libpypy-c.so #5 0x00007f126ac767c1 in ?? () from /data/tgp/pallas/pypy2-5.7.0-alpha0-tlinux1.2/bin/libpypy-c.so #6 0x00007f126ac774aa in ?? () from /data/tgp/pallas/pypy2-5.7.0-alpha0-tlinux1.2/bin/libpypy-c.so #7 0x00007f126ac77f41 in ?? () from /data/tgp/pallas/pypy2-5.7.0-alpha0-tlinux1.2/bin/libpypy-c.so #8 0x00007f126ac78ada in ?? () from /data/tgp/pallas/pypy2-5.7.0-alpha0-tlinux1.2/bin/libpypy-c.so #9 0x00007f126ac7a898 in ?? () from /data/tgp/pallas/pypy2-5.7.0-alpha0-tlinux1.2/bin/libpypy-c.so #10 0x00007f125e5c4c3f in ?? () #11 0x00007f126cd787b0 in ?? () #12 0x00007f125d92c05b in ?? () #13 0x00000000039ffc48 in ?? () #14 0x00007f1264d9d9a8 in ?? () #15 0x00007f126cd0c020 in ?? () #16 0x00007f126bae13c0 in ?? () from /data/tgp/pallas/pypy2-5.7.0-alpha0-tlinux1.2/bin/libpypy-c.so #17 0x000000000000002d in ?? () #18 0x00007f1264da11e8 in ?? () #19 0x0000000003225bc0 in ?? () #20 0x00007f126aa349e2 in ?? () from /data/tgp/pallas/pypy2-5.7.0-alpha0-tlinux1.2/bin/libpypy-c.so #21 0x00007f125e29c7b0 in ?? () #22 0x00007f126af7dc80 in ?? () from /data/tgp/pallas/pypy2-5.7.0-alpha0-tlinux1.2/bin/libpypy-c.so #23 0x00007fff88689fc8 in ?? () #24 0x00007fff88689e70 in ?? () #25 0x0000000000000003 in ?? () #26 0x00007f126cd787b1 in ?? () #27 0x00007f125d92eee6 in ?? () #28 0x0000000003225bc0 in ?? () #29 0x00007f126a9ab5fb in ?? () from /data/tgp/pallas/pypy2-5.7.0-alpha0-tlinux1.2/bin/libpypy-c.so #30 0x00007f1268546e80 in ?? () from /lib64/libc.so.6 #31 0x0000000003d38850 in ?? () #32 0x00007f126cd0c020 in ?? () #33 0x0000000002657558 in ?? () #34 0x00007f125e29aa10 in ?? () #35 0x0000000000000000 in ?? () (gdb) ``` -- Unwatch this issue to stop receiving email updates: https://bitbucket.org/api/1.0/repositories/pypy/pypy/issue/2470/unwatch/pypy-issue/e1044d1a59b5b796d254dae6600369929fed1e5c/ From issues-reply at bitbucket.org Sun Jan 22 02:31:53 2017 From: issues-reply at bitbucket.org (longriver) Date: Sun, 22 Jan 2017 07:31:53 -0000 Subject: [pypy-issue] [Bitbucket] Issue #2470: Random crash when using gevent with some IO pressure (pypy/pypy) In-Reply-To: References: Message-ID: --- you can reply above this line --- Issue 2470: Random crash when using gevent with some IO pressure https://bitbucket.org/pypy/pypy/issues/2470/random-crash-when-using-gevent-with-some longriver: crash 3 times in one hour when running another program, core reason all are:cannot find gc roots! Changes: status: resolved -> open -- Unwatch this issue to stop receiving email updates: https://bitbucket.org/api/1.0/repositories/pypy/pypy/issue/2470/unwatch/pypy-issue/e1044d1a59b5b796d254dae6600369929fed1e5c/ From issues-reply at bitbucket.org Mon Jan 23 11:25:31 2017 From: issues-reply at bitbucket.org (Brian Rak) Date: Mon, 23 Jan 2017 16:25:31 -0000 Subject: [pypy-issue] Issue #2471: dump_rpy_heap throws an exception (pypy/pypy) Message-ID: <20170123162531.3053.88576@celery-worker-108.ash1.bb-inf.net> New issue 2471: dump_rpy_heap throws an exception https://bitbucket.org/pypy/pypy/issues/2471/dump_rpy_heap-throws-an-exception Brian Rak: ``` #!python # /root/pypy3.3-5.5-alpha-20161013-linux_x86_64-portable/bin/pypy Python 3.3.5 (ea9979b550eeae87924dc4bef06070e8f8d0e22f, Oct 13 2016, 11:32:23) [PyPy 5.5.0-alpha0 with GCC 6.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``a 10th of forever is 1h45'' >>>> import gc >>>> gc.dump_rpy_heap('aaaa') Traceback (most recent call last): File "", line 1, in TypeError: 'str' does not support the buffer interface ``` This works if you pass in a file object instead. I'd guess it's related to gc.get_typeids_z, as trying to dump to a file this results in a similar error From issues-reply at bitbucket.org Thu Jan 26 16:00:31 2017 From: issues-reply at bitbucket.org (Chris Muller) Date: Thu, 26 Jan 2017 21:00:31 -0000 Subject: [pypy-issue] Issue #2472: Access violation writing location 0x00000000. (pypy/pypy) Message-ID: <20170126210031.38012.26517@celery-worker-107.ash1.bb-inf.net> New issue 2472: Access violation writing location 0x00000000. https://bitbucket.org/pypy/pypy/issues/2472/access-violation-writing-location Chris Muller: pypy.exe crashes eventually when running my application. Sometimes it takes 30 minutes or more to crash, but it always eventually crashes. Here's the full error message: Unhandled exception at 0x776B6B97 (ntdll.dll) in pypy.exe: 0xC0000005: Access violation writing location 0x00000000. I am running on Windows 10, and the project uses Tornado and some thread calculations, but I have yet to pinpoint what exactly is causing this error since it takes so long to trigger it. Wanted to make the team aware in case they have some idea of what causes this. I am mostly avoiding pypy for now due to this bug, even though it gives me great performance up until the crash. I am aware that Tornado is not officially supported on Windows, which may be part of the issue - however, my project runs perfectly using standard Python. From issues-reply at bitbucket.org Sat Jan 28 04:50:43 2017 From: issues-reply at bitbucket.org (Armin Rigo) Date: Sat, 28 Jan 2017 09:50:43 -0000 Subject: [pypy-issue] [Bitbucket] Issue #2470: Random crash when using gevent with some IO pressure (pypy/pypy) In-Reply-To: References: Message-ID: --- you can reply above this line --- Issue 2470: Random crash when using gevent with some IO pressure https://bitbucket.org/pypy/pypy/issues/2470/random-crash-when-using-gevent-with-some Armin Rigo: It's a different bug. For this kind of bug, we need a way to reproduce the problem. An archive containing the code you try to run, together with exact version numbers of PyPy, should be enough. Without this, we can't do anything. -- Unwatch this issue to stop receiving email updates: https://bitbucket.org/api/1.0/repositories/pypy/pypy/issue/2470/unwatch/pypy-issue/e1044d1a59b5b796d254dae6600369929fed1e5c/