Mailman 3 November 2017 - pypy-issue

Issue #2704: Undefined behavior in RPython via the C backend (pypy/pypy)
by Carl Friedrich Bolz-Tereick 28 Nov '17

28 Nov '17

New issue 2704: Undefined behavior in RPython via the C backend https://bitbucket.org/pypy/pypy/issues/2704/undefined-behavior-in-rpython-v… Carl Friedrich Bolz-Tereick: We did not completely decide so far whether int-addition (and other ops) in RPython must behave a) by wrapping around or b) by having undefined behavior on overflow. Right now, the C backend and parts of the JIT implements b). However, we definitely have code where we use int operations that overflow and we expect a), most notably a lot of hash computations (eg ``W_TupleObject._descr_hash_*``). This has the potential (maybe unlikely though?) of causing miscompilation of PyPy at any point in the future when GCC (or the JIT) gets smarter about reasoning about ints.

1 0

Issue #2703: PyPy3 bitfields reversed from expected value (pypy/pypy)
by Holger Grund 21 Nov '17

21 Nov '17

New issue 2703: PyPy3 bitfields reversed from expected value https://bitbucket.org/pypy/pypy/issues/2703/pypy3-bitfields-reversed-from-e… Holger Grund: Bitfields in BigendianStructures are not allocated in the same way as for CPython on x86-64 Linux at least. Per ABI big-endian bitfields should be allocated from high to low bit, but PyPy’s ctypes doesn’t do that. Observe: ``` #!python import ctypes class Foo(ctypes.BigEndianStructure): _fields_ = ( ('first', ctypes.c_uint8, 4), ('second', ctypes.c_uint8, 4)) f = Foo(first=0,second=15) print('%r' % list(bytes(f))) ``` PyPy3 prints [240]. CPython prints [15].

1 0

Issue #2702: pypy3 5.9.0 not available for maxos64 (pypy/pypy)
by davoud taghawi-nejad 17 Nov '17

17 Nov '17

New issue 2702: pypy3 5.9.0 not available for maxos64 https://bitbucket.org/pypy/pypy/issues/2702/pypy3-590-not-available-for-max… davoud taghawi-nejad: there is no pypy3 5.9.0 available for maxos64. Responsible: mattip

1 0

Issue #2701: Future imports not allowed after docstrings (pypy/pypy)
by Davide Depau 13 Nov '17

13 Nov '17

New issue 2701: Future imports not allowed after docstrings https://bitbucket.org/pypy/pypy/issues/2701/future-imports-not-allowed-after Davide Depau: The [Python language reference](https://docs.python.org/2/reference/simple_stmts.html#future) clearly states that future statements are allowed after docstrings: > A future statement must appear near the top of the module. The only lines that can appear before a future statement are: > > - the module docstring (if any), > - comments, > - blank lines, and > - other future statements. However PyPy seems not to like it very much. See my pull request to OctoPrint: https://github.com/foosel/OctoPrint/pull/2217 The fact that in some file there is a future import, a docstring and then another future import makes PyPy crash, while CPython accepts it just fine. ``` SyntaxError: __future__ statements must appear at beginning of file ``` Code that triggers it: ```python from __future__ import absolute_import """ [Module docstring] """ from __future__ import absolute_import, division, print_function ``` While this obviously the best code one could write (in fact they merged my PR that fixes it), it still valid and PyPy should accept it.

1 0

Issue #2700: slow warmup running Firefox taskgraph generation (pypy/pypy)
by Chris AtLee 10 Nov '17

10 Nov '17

New issue 2700: slow warmup running Firefox taskgraph generation https://bitbucket.org/pypy/pypy/issues/2700/slow-warmup-running-firefox-tas… Chris AtLee: To reproduce: - clone https://hg.mozilla.org/mozilla-central revision 2e4bef09de27 - download https://queue.taskcluster.net/v1/task/dcvqqnj4RkaJGACao955TA/runs/0/artifac… - run `time pypy ./mach taskgraph target -p parameters.yml > /dev/null` this takes about 20s on my system next, modify taskcluster/mach_commands.py so that we duplicate the call to show_taskgraph: ``` diff --git a/taskcluster/mach_commands.py b/taskcluster/mach_commands.py --- a/taskcluster/mach_commands.py +++ b/taskcluster/mach_commands.py @@ -79,16 +79,17 @@ class MachCommands(MachCommandBase): @ShowTaskGraphSubCommand('taskgraph', 'full', description="Show the full taskgraph") def taskgraph_full(self, **options): return self.show_taskgraph('full_task_graph', options) @ShowTaskGraphSubCommand('taskgraph', 'target', description="Show the target task set") def taskgraph_target(self, **options): + self.show_taskgraph('target_task_set', options) return self.show_taskgraph('target_task_set', options) @ShowTaskGraphSubCommand('taskgraph', 'target-graph', description="Show the target taskgraph") def taskgraph_target_taskgraph(self, **options): return self.show_taskgraph('target_task_graph', options) @ShowTaskGraphSubCommand('taskgraph', 'optimized', ``` re-run `mach taskgraph`. This time is takes about 34 seconds. I think this means that the second pass only takes 14 seconds to run.

1 0

Issue #2699: warnings.warn fails with non-ascii unicode strings on PyPy2 5.9.0 (pypy/pypy)
by Bruno Oliveira 09 Nov '17

09 Nov '17

New issue 2699: warnings.warn fails with non-ascii unicode strings on PyPy2 5.9.0 https://bitbucket.org/pypy/pypy/issues/2699/warningswarn-fails-with-non-asc… Bruno Oliveira: Hi, `warnings.warn` in recent versions breaks when passed `non-ascii` unicode on Windows: ```python # -*- coding: utf8 -*- import warnings warnings.warn(u"测试") ``` Running this produces this output: ``` C:\pytest\.pypy\bin\pypy.exe C:/pytest/.tmp/test_pypy_unicode.py Traceback (most recent call last): File "C:/pytest/.tmp/test_pypy_unicode.py", line 3, in <module> warnings.warn(u"测试") UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128) ``` I'm not sure in which version this started to break, but we detected this on the pytest's test suite when a test started to break all of sudden. [Here's a link](https://ci.appveyor.com/project/pytestbot/pytest/build/1.0.3355/job/1… to one of the AppVeyor failures. Interestingly, running the same code under CPython does not produce **any** output and returns zero to the OS. But if we change the string to something `ascii` compatible, than both CPython and PyPy print the correct output: ``` pypy .tmp\test_pypy_unicode.py .tmp\test_pypy_unicode.py:4: UserWarning: foo warnings.warn('foo') ``` ``` python.exe .tmp\test_pypy_unicode.py .tmp\test_pypy_unicode.py:4: UserWarning: foo warnings.warn('foo') ``` **PyPy2 version info** ``` pypy --version Python 2.7.13 (c2437cf9b7f1, Sep 24 2017, 17:23:53) [PyPy 5.9.0 with MSC v.1500 32 bit] ``` Thanks for all the hard work!

1 0

Issue #2698: Suspected memory leak with pysnmp==4.4.1 on PyPy 5.9 only (Python seems fine) (pypy/pypy)
by Edward Beech 07 Nov '17

07 Nov '17

New issue 2698: Suspected memory leak with pysnmp==4.4.1 on PyPy 5.9 only (Python seems fine) https://bitbucket.org/pypy/pypy/issues/2698/suspected-memory-leak-with-pysn… Edward Beech: The code to reproduce is fairly simple- obviously you'll need PyPy 5.9 installed first as well as pysnmp==4.4.1. ``` #!python from pysnmp.hlapi import SnmpEngine, UdpTransportTarget, ContextData, ObjectType, ObjectIdentity, getCmd, UsmUserData, usmHMACSHAAuthProtocol, usmAesCfb128Protocol ITERATIONS = 65536 for i in range(0, ITERATIONS): snmp_engine = SnmpEngine() context_data = ContextData() errorIndication, errorStatus, errorIndex, varBinds = next( getCmd( snmp_engine, UsmUserData( userName='some_username', authKey='some_auth_key', privKey='some_priv_key, authProtocol=usmHMACSHAAuthProtocol, privProtocol=usmAesCfb128Protocol, ), UdpTransportTarget( ('some_host', 161), timeout=5, retries=2, ), context_data, ObjectType(ObjectIdentity('.1.3.6.1.2.1.1.5.0')) ) ) print '{0}/{1} - {2}'.format(i + 1, ITERATIONS, varBinds) del snmp_engine del context_data ``` Under PyPy 5.9 memory use steadily increases until (in my experience) MacOS crashes; in Python however, all seems fine. I've also raised an issue on the [PySNMP Github page.](https://github.com/etingof/pysnmp/issues/103)

1 0

Issue #2697: [patch] fix compilation on FreeBSD (pypy/pypy)
by David Naylor 01 Nov '17

01 Nov '17

New issue 2697: [patch] fix compilation on FreeBSD https://bitbucket.org/pypy/pypy/issues/2697/patch-fix-compilation-on-freebsd David Naylor: - cpyext: make 'darwin' the fall-through case to define (compile|link)_extra as None. Fixes use-before-define error - rvmprof: - on FreeBSD PyPy needs to link to libunwind - fix missing ';' in statement - indicate unwind functions only need to support local (makes linking easier on FreeBSD)

1 0

Issue #2696: [patch] fix various tests on FreeBSD (pypy/pypy)
by David Naylor 01 Nov '17

01 Nov '17

New issue 2696: [patch] fix various tests on FreeBSD https://bitbucket.org/pypy/pypy/issues/2696/patch-fix-various-tests-on-free… David Naylor: Enable tests that now run on FreeBSD: - termios - pyrepl (and fix skipif on 'freebsd', instead of the more limited case 'kfreebsd') Mark tests as xfail on FreeBSD: - _vmprof.test_get_profile_path Sundry: - test_recompile: libc++ defines char16_t and char32_t for __cplusplus < 201103

1 0

Issue #2695: [patch] fail early in ll2types for RTLD code (pypy/pypy)
by David Naylor 01 Nov '17

01 Nov '17

New issue 2695: [patch] fail early in ll2types for RTLD code https://bitbucket.org/pypy/pypy/issues/2695/patch-fail-early-in-ll2types-fo… David Naylor: When looking up the dl* functions from the rtld_default_lib, instead of using the helper and falling through to the standard library, directly lookup the function and fail if not found. Failure here is correct as rtld_default_lib is required to provide the specified functions. Also, fix the name of the library: the dl* functions are provided by elf-ld.so.1.

1 0