demonimin has quit [Remote host closed the connection]
kristina_ is now known as kristina
<arigato>
looking at issue 2904 (jit-and-the-copy-module-causes...)
<arigato>
guess what? if I disable unrolling then it works
<arigato>
Who Would Have Guessed
jamesaxl has joined #pypy
adamholmberg has joined #pypy
adamholmberg has quit [Remote host closed the connection]
themsay has quit [Ping timeout: 245 seconds]
nimaje has quit [Quit: WeeChat 2.3]
nimaje has joined #pypy
antocuni has joined #pypy
Zaab1t has joined #pypy
<arigato>
ok what How Could It Ever Have Worked
<LarstiQ>
heh
<cfbolz>
arigato: pff, that issue sucks
<cfbolz>
I looked for an afternoon, but didn't get anywhere
<arigato>
re-pff
<arigato>
I think that debug_print() is interacting with the rest of the debug logs
<cfbolz>
likely, yes
<arigato>
so even in running "pypy z.py", if z.py contains debug_print(), then they will normally be printed, but they will be swallowed if they happens when the JIT is also running
<arigato>
or something like that
<arigato>
that suddenly makes relying on debug_print() for debugging a Very Bad idea
<cfbolz>
right
<antocuni>
arigato: you mean __pypy__.debug_print?
<arigato>
antocuni: yes
<antocuni>
ouch :(
<antocuni>
I think that the point of it is explicitly to be written in the log; so I am more surprised that it prints to stdout when there is no log than viceversa
<cfbolz>
arigato: anyway, the problem is visible with regular print too, no?
<arigato>
yes, but the last 15 minutes I spent were chasing a wrong problem
<arigato>
(and the 15 minutes afterwards were to make sure that all the previous work was not chasing a wrong problem)
<cfbolz>
:-(
<arigato>
I think it's something like that:
<arigato>
for c in range(3):
<arigato>
h = height
<arigato>
while h > 0:
<arigato>
h -= 1
<arigato>
at one point it traces from "before the while" with the value of h that happens to be 0, by chance
<arigato>
so it traces around the "for", until it closes the loop when it comes back to "before the while"
<arigato>
then it unrolls this loop, which doesn't make much sense because this loop will never run twice in a row
<arigato>
but which is probably OK
<arigato>
the problem occurs when later another bridge is compiled, which jumps to the label in the middle of this unrolled loop
<cfbolz>
yes
<cfbolz>
so it's some kind of weird merging problem
<arigato>
something like, the unrolled (2nd) version is using some condition found in the previous iteration
<arigato>
which is not correctly recorded and checked
<cfbolz>
yes
<cfbolz>
which is super weird, because one would expect that this should have been found earlier
<cfbolz>
particularly since the loop is so simple, only ints, nothing fancy
<cfbolz>
arigato: does it fail if you turn the outer loop into a while loop?
<arigato>
yes
<cfbolz>
arigato: so that's the last piece of heap-y stuff gone, the for iterator
<arigato>
there's still the W_IntObjects
<cfbolz>
yep
<cfbolz>
but nothing nested at all
<arigato>
no
<cfbolz>
arigato: I suppose we could try to write a JIT test without pypy, but that's always a pain
<arigato>
I'm trying to
<arigato>
it's no longer a pain, from such a small piece of code
<cfbolz>
:-)
<arigato>
except I didn't manage to reproduce so far, of course
<cfbolz>
I like your optimism
<arigato>
except I didn't manage to reproduce so far, of course
<arigato>
oops
<arigato>
I think it's related to having two loops, somehow
<cfbolz>
yes, definitely
<arigato>
if I unroll the outer loop manually, even by writing three calls to a function that contains the inner loop, then it works
<cfbolz>
right
<cfbolz>
another idea could be to write this simple loop in one of the TLA languages
<arigato>
it only fails if *all* variables are IntVals; even using a plain int for one of them makes the test pass
<cfbolz>
Amazing
<cfbolz>
arigato: but it doesn't fail with lldebug?
<arigato>
still building a lldebug
<cfbolz>
arigato: I vaguely remember a previous bug related to this assert
* arigato
committed the test to default, just in case you wonder
<cfbolz>
arigato: thanks
<arigato>
so no, an lldebug build doesn't fail on the pure python example...
<arigato>
ah wait
<arigato>
...no, doesn't fail
<arigato>
ah wait again
<arigato>
that assertion is protected by "if not we_are_translated()"...
<cfbolz>
Ugh
<cfbolz>
Why is that
<arigato>
maybe because of the cost? it does "x in lst"
<cfbolz>
True
<arigato>
though in this simple case, the list is just empty when the assert fails
<cfbolz>
Right
<cfbolz>
arigato: notice this in the test: Virtual states did not match after picking the virtual state, when forcing boxes
<arigato>
yes
<cfbolz>
arigato: I wonder whether this is an unrelated issue, however. if I disable the assert, I don't get the wrong merge
<cfbolz>
in the test
<cfbolz>
arigato: we agree that the thing that is most wrong is the fact that the second bridge doesn't go to the preamble, but to the inner loop, right?
<arigato>
...not so far
<arigato>
I didn't manage to really understand why I was getting a wrong result
<cfbolz>
ok :-)
<arigato>
it goes to the inner loop, but it starts with a guard that should fail and jump to the bridge again
<arigato>
...and indeed, if I just comment out the assert, then the test passes
<arigato>
but the real pypy run gives the wrong result
<cfbolz>
right
<cfbolz>
arigato: I still think what you found is an important bug
mattip has joined #pypy
<arigato>
possibly, but also possibly a different one?
<cfbolz>
yes, I suspect so
<cfbolz>
mattip: hey!
<cfbolz>
arigato: fwiw, my tla experiments the same is true: I don't manage to make it jump to the inner loop
<arigato>
so we're back to square one, with an extra unrelated bug in the corner
<cfbolz>
:-) "progress"
<cfbolz>
arigato: it's super annoying, because superficially the traces look "right"
<cfbolz>
except that the merging is different
<cfbolz>
arigato: we could do the extreme thing and try to run pypy on llinterp again, but that's waiting waiting waiting
<arigato>
yes, and unsure there is much to learn from that
<cfbolz>
maybe, indeed
marky1991 has joined #pypy
<cfbolz>
arigato: OK, need to get Henri now, will try to look at the problem soon a bit more
<fijal>
armin went for lunch
jcea has joined #pypy
jcea has quit [Remote host closed the connection]
<arigato>
cool
<arigato>
thanks, I'll switch to other things here for a bit
jcea has joined #pypy
mattip_ has joined #pypy
<arigato>
I thought there was a revdb crash but it's likely just because of a version mismatch
mattip has quit [Ping timeout: 268 seconds]
Rhy0lite has joined #pypy
lritter has joined #pypy
adamholmberg has joined #pypy
adamholmberg has quit [Remote host closed the connection]