New issue 1919: Problematic strings returned from os.read https://bitbucket.org/pypy/pypy/issue/1919/problematic-strings-returned-from-osread
Philip Jenvey: Here's a nasty one. The attached script fails on recent pypys (result in d should be True). tannit can reproduce it w/ a recent pypy2 no-jit build: http://buildbot.pypy.org/nightly/trunk/pypy-c-nojit-74318-ffce4c795283-linux64.tar.bz2 (it may take no more than a few tries before it prints a bogus result of "False\nTrue") AFAICT the rpython level string's hash code seems bogus. The bad string's from an os.read w/ count 1 specified resulting in a string of length 1. I haven't tracked down to when this began happening but I recall it beginning to exhibit itself on PyPy3 at least a couple weeks ago in the most unrelated way (backspace in pyrepl began raising an exception). Doesn't happen in 2.4.0 release (pypy2 & pypy3) I suspect the pinning/zeroing changes aren't clearing out the initial hash code but that's just a guess, so far I can't see how that would even happen _______________________________________________ pypy-issue mailing list pypy-issue@python.org https://mail.python.org/mailman/listinfo/pypy-issue
