cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | Matti: I made a bit of progress, the tests now only segfault towards the end
epony has quit [Ping timeout: 260 seconds]
nimaje has quit [Ping timeout: 260 seconds]
otisolsen70 has joined #pypy
nimaje has joined #pypy
slav0nic has joined #pypy
otisolsen70 has quit [Quit: Leaving]
epony has joined #pypy
Dejan has joined #pypy
lritter has joined #pypy
otisolsen70 has joined #pypy
komasa2 has joined #pypy
otisolsen70_ has joined #pypy
otisolsen70 has quit [Ping timeout: 260 seconds]
otisolsen70_ has quit [Quit: Leaving]
<komasa2> Somewhat conceptual question about pypy: Does pypy optimize based on the assumption that if `x == y` then the objects are interchangeable? Specifically, if there is a object variable that isn't checked in the `__eq__` implementation?
<komasa2> I'm chasing down some confusing failure in my test case here, that seems to be influenced by e.g. a _different_ testcase
<cfbolz> komasa2: this can happen for ints, floats and stuff like that, but it should not be observable
komasa2 is now known as komasa
<mattip> is there some OS resource (socket, file, mmap) involved? Perhaps you are depending on refcount semantics to close or release the resource.
<mattip> does changing the order of the tests change anything?
<komasa> Shouldn't involve any OS resource directly
<komasa> The order of the test does change things, but currently I can also get it to fail with just one test
<mattip> can you share the general workflow of the test?
<komasa> The core issue is: There is some kind of class that consists of basically three values, let's call them "x" "y" and "tags". `tags` is a set of other objects
<komasa> The __hash__ and __eq__ method of this object only take x and y into account
<cfbolz> komasa: it there some way we can run this ourselves?
<komasa> cfbolz: not really, if there was I'd just be bugging the maintainer of the underlying library code directly :/
<cfbolz> komasa: ok
<komasa> this is some interaction between code for work I can't share, and library code (
<cfbolz> komasa: did you try to run pypy with '--jit off'?
<komasa> Can I somehow pass that to pytest? Because one of the baffling behavior is that directly running the test with the interpreter also doesn't fail the test
<cfbolz> komasa: pypy --jit off -m pytest
<komasa> Still fails
<cfbolz> Good
<cfbolz> A jit bug would be much more disconcerting
<cfbolz> komasa So I fear now it's down to trying to minimize the problem :-(
<komasa> That's okay, I have been doing that for hours at this point, my inital question was already part of that process :)
<komasa> I'm still not 100% sure this is a just a pypy issue, it might just need a different setup to trigger with CPython
<cfbolz> komasa: let us know if we can help in some way
<cfbolz> komasa: out of curiosity, what are you using PyPy for?
<komasa> Uh, "make Python code go fast"
<komasa> We are doing large scale program analysis with the angr Framework
<cfbolz> That's extremely generic 😂
<cfbolz> komasa: cool
<cfbolz> If you ever want to write a guest post on the PyPy blog on that, we would be very interested
<komasa> About the general thing we do?
<komasa> The angr framework specifically recommends pypy as a tool for speeding it up btw:
<cfbolz> komasa: yep, and how PyPy is involved
<mattip> a quick search for "open(" in angr turns up things like this line, that never closes fd
<komasa> Ah, that is more complicated than that though
<komasa> That code basically is a python abstraction that simulates the actual "fopen" library call
<komasa> Which is only ever called during a specific kind of "emulation" of assembly code
<cfbolz> And I suspect you don't know when to call close, since that's up to the binary
<komasa> This shouldn't actually ever call the real "open" function from python
<mattip> ok, just something easy to grep for. There are more like it
<komasa> Fair enough. Though I am not sure how that could cause this issue
<komasa> (the asserts are added by me)
<mattip> anyhow, my point is that if you are getting the error with "--jit off", then that should move the spotlight to the garbage collector differences between PyPy and CPython
<komasa> WOuld the GC somehow reuse objects with the same hash?
<komasa> My strong suspicion is that this is related to the __hash__ implementation somehow, because my problem is that I basically getting the same object (according to the __hash__) but the tags are empty.
<komasa> And this objects gets moved into sets/dicts a lot
<komasa> so maybe something like { Foo(1,2, {}) } | { Foo(1,2, {"bar"} } where the __hash__ method only uses the first two parameters
<komasa> Both the set containing just the `Foo(1,2, {})` or the set containing just `Foo(1,2, {"bar"})` would seem like valid results in that case
<cfbolz> no, the GC doesn't care about the __hash__
<cfbolz> komasa: hm, is it specifically dicts that are involved?
<cfbolz> Sets, I mean?
<cfbolz> There's one behavior difference between sets in cpython and PyPy, which is that sets are insertion ordered in PyPy, like dicts. In cpython the order is arbitrary (and based on the hashes)
lritter has quit [Ping timeout: 240 seconds]
Dejan has quit [Quit: Leaving]
slav0nic has quit [Ping timeout: 260 seconds]