github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
brrt \o 10:43
dogbert2 yay it's brrt
brrt ohai dogbert2
anything broken in the meantime? :-)
dogbert2 yes :-)
brrt brrt-to-the-future.blogspot.com/201...fork2.html
tell me
dogbert2 can you run this? MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./perl6 t/04-nativecall/00-misc.t 10:44
I get a test failure containing 'JIT ERROR: Negative offset for dynamic label 50' 10:45
brrt let me see..
dogbert2 let me add that I have commit ceea63332b9c4a2 10:47
brrt I kind of hate those perl6 tests that use subprocesses 10:48
dogbert2 interesting, I noticed the problem when running htmlify.p6 yesterday and I believe that it also uses subprocesses 10:49
brrt but, yes, I'll take a loop 12:14
*look
lizmat
.oO( loop-di-look )
 12:22
brrt ok, I have a small reproduction 12:38
dogbert2 cool, was it easy to find? 12:45
brrt well, I just took the sample out of the test 12:50
dogbert2 so now you have to figure out what's happening in the JIT 12:57
brrt presumably we're not emitting some label that we expect 12:58
dogbert2 stupid question perhaps but how serious is this problem? 12:59
brrt That depends on perspective 13:00
In theory, this is really bad
It could lead to infinite loops, missed handlers, etc
In practice, this particular bug is probably innocent
dogbert2 in that case it's a definite improvement that they are now emitted to STDOUT 13:03
brrt stderr, actually 13:04
but yes
dogbert2 my bad 13:05
brrt :-) 13:08
AlexDaniel squashable6: next 13:09
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in ≈20 hours (2018-10-06 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
brrt oh, I think I understand now.... 16:41
interestingly, the error is actually in the legacy JIT 16:42
if we have an annotation that requires us to have a label after an opcode (as happens with inline-end labels, is that actually correct though?) 16:43
... and, if that annotation is processed by the expression JIT
then we allocate a label for it. But if it happens to be an opcode that is processed as a block by the legacy JIT (prepargs is that way), then we don't process that annotation in the legacy JIT 16:44
so what happens is
- we allocate a label in the expression JIT 16:45
- we don't have the template, so we don't emit anything
- the legacy JIT skips adding the label
- the new check screams loudly about it
now, I have just two questions... 16:46
in this case, we're seeing an inline_end annotation on a prepargs
brrt and I was operating under the assumption that inline_end would be the *inclusive* end of the inline 16:46
but how can prepargs be the last opcode in the inline?
timotimo perhaps it comes from a spesh plugin, brrt? 17:31
hm, no, spseh plugins wouldn't have a prepargs any more
brrt hmm 17:34
this needs to be more resilient
timotimo did you look at the rules that govern how annotations move when instructions get removed? 17:35
brrt did not
anyway, i'm off for today
:-)
timotimo o/ 17:37
lizmat m: CONTROL { }; warn "foo" # panic! 19:02
camelia foo
MoarVM panic: Trying to unwind over wrong handler
lizmat am I doing something wrong here ? 19:03
jnthn Apparently :P 19:04
I'm not sure what's happening there, though. It should be a no-op 19:05
(you don't smart-match on the control exception, so it's re-thrown to the normal warn handler, which then resumes)
lizmat should I ticket this. And if so, where? Rakudo? 19:06
timotimo i believe this has been happening for many years, and people have stumbled upon it multiple times 19:08
jnthn Yeah, I've seen at least similar before, if not identical
It's probably even filed somewhere
lizmat ok, I'll leave it then 19:13
is there actually a way to export a CONTROL block ? 19:20
dogbert17 jnthn, lizmat: here's an old report, github.com/MoarVM/MoarVM/issues/572 19:25
lizmat that's weird to see: I *was* goofing around with CONTROL, having completely forgotten about the report 19:27
but the code I tried was *exactly* the code I reported on Jan 10
so much for memory :-(
dogbert17 it has sometimes happened that when entering a room in order to accomplish a task, figured out a few seconds earlier, I have forgotten why I went there 19:30
I have to stop and think
jnthn lizmat: No, no way to export phasers yet 19:50
lizmat: Maybe some day an export macro or some such... :)
lizmat :-(
masak hm 20:46

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!