10:13 <komasa> cfbolz: At some point in the library code it involves Sets, at some point probably dicts

14:06 <mattip> when I try to run

14:06 <mattip> pypy2 pytest.py -A --python=pypy3.8 pypy/module/cpyext/test/test_unicodeobject.py

14:07 <mattip> on py3.8, all the tests are skipped with

14:07 <mattip> pypy/tool/pytest/objspace.py:69: cannot runappdirect test:

14:07 <mattip> space needs objspace.disable_entrypoints_in_cffi = True, while pypy-c was built with None

14:07 <mattip> they run find with

14:08 <mattip> python2 pytest.py -A --python=pypy3.8 pypy/module/cpyext/test/test_unicodeobject.py

14:11 <mattip> strangely, the macOS buildbot does run the tests using pypy2

15:30 <cfbolz> mattip: wasn't that what matt was saying he plans to do on pypy-dev?

15:31 <komasa> cfbolz: Managed to also trigger my bug with CPython, though the output still differs somewhat. Somehow CPython gets 2 out of the 4 objects correct still.

15:31 <komasa> So this is most likely _not_ a pypy bug, and just some code relying on something that shouldn't be relied upon

15:43 <mattip> cfbolz: right, the buildbot is fine. The top of the rabbit hole is the CI failure with pypy3.8 + macOS + cython

15:43 <mattip> https://github.com/pypy/binary-testing/runs/6067983908?check_suite_focus=true

15:44 <cfbolz> komasa: yes, some pypy rejiggling might make the bug more likely

15:44 <mattip> so I started looking at running the cpyext tests around unicode, which is what is failing,

15:45 <mattip> and then tried to run some tests, and then came up against the phenomenon that -A fails locally but passes on the buildbot

15:46 <cfbolz> mattip: right

15:46 <cfbolz> do the cpyext tests work on default on pypy2?

16:06 <mattip> yes, pypy2 pytest.py -A pypy/module/cpyext/test/test_unicode.py runs the tests without skipping them

16:17 <komasa> I think I found the bug. The library was using a WeakValueDictionary deep inside the code

16:18 <cfbolz> ah :-(

16:25 <komasa> Though the code around this was specifically for some caching stuff, that explicitly says that if an object of some hash exists already, the cached one will be returned.

16:25 <LarstiQ> the key here might be, when exactly does it exist?

16:26 <komasa> Oh, that I know

16:26 <komasa> At this point this is an oversight in the library that I think I fully understand

16:28 <komasa> My other test cases where already running certain code that created objects that had the same hash

19:00 <ronan> mattip: I fixed it with 64de87cccf29 though I wish the differences between py2 and py3 were clearer in the code

19:51 <mattip> ronan: thanks