cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
<arigo>
aargh, "did you know" that PyArg_ParseTuple() when using just a couple of format codes ("es", "et"), returns to you a pointer that you actually have a free
<arigo>
it's written in a far-away corner of the documentation
<arigo>
time to grep through my projects (notably cffi) to see how many times I leak
<cfbolz>
:-(
<cfbolz>
hi Armin!
<arigo>
morning!
<arigo>
cfbolz: btw you asked in an issue if the jit crash rings a bell: no, it doesn't
<cfbolz>
how are you doing?
<arigo>
fine, thanks
<cfbolz>
arigo: it looks really bizarre :-(
<cfbolz>
probably an interaction of jitting at just the wrong deep stack level and vmprof
<arigo>
maybe getting the RecursionError from somewhere inside the JIT, leaving the vmprof stack unbalanced
<cfbolz>
arigo: yes, that's kind of what I suspect
<cfbolz>
arigo: bit annoying to fix
<arigo>
yes
<cfbolz>
maybe we can at least not crash though
<cfbolz>
arigo: yes, there's one too many entries on the rvmprof stack
<cfbolz>
arigo: should I add a hack that checks whether the previous frame looks correct and then pops two? it's a bit terrible, but it also feels unsatisfying to crash because of vmprof, which isn't even enabled
<arigo>
but is vmprof the only problem here? is e.g. the sys.getframe() stack also off by one?
<cfbolz>
good question
<arigo>
you can certainly add this hack and try again to see if the problem seems to disappears
<cfbolz>
might eventually go for that
<cfbolz>
but maybe I can diagnose a bit more where it goes wrong first
<cfbolz>
arigo: thanks for the idea of looking at the actual frame