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
proteus-guy has quit [Remote host closed the connection]
<arigato>
maybe the "executable" protection flags are missing?
<arigato>
but I guess it wouldn't be SIGILL
<tumbleweed>
in some other runs I got segfaults
<tumbleweed>
but I get that SIGILL quite often (maybe 50% of the time)
<tumbleweed>
seeing if I can reproduce it on 7.3.3
<tumbleweed>
no idea what the best strategy for digging into the source of that is
<tumbleweed>
yep, reproduced on 7.3.3
<arigato>
maybe it occurs because the L1 instruction cache was not invalidated properly, so it crashes by reading a random instruction from the cache just after the JIT emitted it, and of course gdb shows the right instruction
<tumbleweed>
yeah, that was the first thougth of the debian arm people too
<arigato>
no, as far as I can tell, we call the Linux function __clear_cache() systematically
oberstet has joined #pypy
Dejan_ has quit [Quit: Leaving]
Dejan has joined #pypy
Dejan has joined #pypy
<tumbleweed>
arigato: OverwritingBuilder looks like it will overwrite without calling __clear_cache()
<tumbleweed>
if that's only patching code before the InstrBuilder will move it and clear cache then that can't be it
<arigato>
no, it's also used later to really change the previously-emitted code
<arigato>
hum
<arigato>
no, right, it's a very thin wrapper class
<arigato>
it's to make changes to an InstrBuilder while it's being generated
<arigato>
before the code is actually written to a fixed memory location
<tumbleweed>
yeah, that's what I was thinking
<arigato>
confusingly enough, actual overwrites of previously-generated instructions is done with three lines "mc = InstrBuilder(); mc.XXX(); mc.copy_to_raw_memory(target_pos)"
<arigato>
like in AssemblerARM.patch_trace()
<tumbleweed>
I can't reproduce these SIGILLs or segfaults on other arm boards we have, so there's something about the Marvell Armada 370/XP that is good at triggering this
<simpson>
Hm, is the board well-cooled? It could be overheating. Sounds stupid but I've had Marvell ARM hardware that only works when kept cool.
<tumbleweed>
we have a bunch of them (and have had for years), so I'd hope so
<simpson>
Aha, it's not just one unit. Well, good to rule that out.
<tumbleweed>
so, these boards don't have NEON, but that doesn't *look* like an issue here
jcea has joined #pypy
<arigato>
in theory it might be a bug in the __clear_cache() function or the underlying rarely-used CPU instruction, but I guess assuming that is the case isn't very useful
lritter has quit [Quit: Leaving]
<simpson>
I was doing research (https://gbracha.blogspot.com/2009/07/miracle-of-become.html) and I came across the following idea: With GC support, transparent forwarders could be automatically removed from heaps whenever they're found. Is this something RPython's GC supports? I have *lots* of transparent forwarders and would love to be able to automatically resolve them.