github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM: ee6ea722c4 | (Stefan Seifert)++ | src/core/interp.c
Fix single byte readint writing to unsigned return register

  Thanks to patzim++ for pointing this out!		 07:53
jnthn morning o/ 09:42
nwc10 \o 09:43
jnthn: ASAN found your most recent changes to be very boring 09:44
lizmat morning * 09:44
jnthn likes keeping ASAN bored 09:50
lizmat m: dd buf8.^find_method("read-int8")(blob8.new(255),0) # this should work, shouldn't it ? 10:05
camelia (signal SEGV)
lizmat m: dd buf8.^find_method("read-int8") 10:07
camelia ForeignCode <anon> = ForeignCode.new
lizmat m: dd buf8.^pun.^find_method("read-int8")(blob8.new(255),0) # ah, it needs to be punned 10:08
camelia -1
jnthn Shouldn't segv though 10:10
lizmat issueize ? 10:11
jnthn Please
Trying to figure out what on earth is happening in github.com/rakudo/rakudo/issues/2519 10:12
nwc10 lizmat: for that SEGV, ASAN just says "SEGV". There's nothing else before it that's undefined behaviour 10:25
lizmat github.com/rakudo/rakudo/issues/2540 10:26
nwc10 jnthn: for github.com/rakudo/rakudo/issues/2519 ASAN reports the same as valgrind 10:28
jnthn Yeah, and it's an invalid read 'cus the index is waaay out of range 10:31
And it was out of range all the way back when the object as placed into the inter-gen set too 10:33
jnthn Got it traced all the way back to the object with the bogus pointer coming out of an SC when a lexical is being vivified...but the object lacks a valid sc_idx/idx. Stranger still, I can't see where on earth it gets allocated. 10:55
nwc10 time for lunch? 10:56
jnthn Ahh...it comes in as a respossession 11:01
m: say 0x43bd668 - 0x43bd538 11:05
camelia 304
jnthn m: say 0x43bd5d0 - 0x43bd538 11:06
camelia 152
jnthn Ah, shite
Yeah, I see what's up
We have an object in SC 1. In SC 2 a mutated version of it has been serialized. So we repossess the object in SC 1. There's been a change of type, so we update the STable too. But the new type has an extra attribute. So what we should do is allocate the extra space for the object, hanging it off the real_data pointer of the P6opaque. But we do't do that, so it goes and deserializes the final attribute, 11:09
overwriting the first pointer-size worth of bytes of whatever comes next. That happens to be the header of another object, thus why it ends up with utterly bogus data in there.
And yeah, lunch, but now I know what it is, it shouldn't take long to fix. 11:11
Geth MoarVM: lizmat assigned to niner Issue nqp::writeint(-1,...) doesn't error correctly github.com/MoarVM/MoarVM/issues/1022
6788cab640 | (Jonathan Worthington)++ | 2 files

This is only an issue for P6opaque, where a change of type might cause a change of size. Thus, we need to allocate and use a new region for the object attributes to be held in. Prior to this change we failed to do that, which meant the deserialization would write over memory that followed the original, now under-size, object body. This was often the ... (5 more lines)		 11:45
lizmat hopes nine doesn't mind
jnthn Got a fix, spectesting. :) 13:40
nine lizmat: I don't :) 13:51
lizmat: already have a pretty good idea for the simple fix and will work on it this evening 13:52
jnthn lizmat: What's the meaning of "returns garbage" in github.com/rakudo/rakudo/issues/2540 ? 13:53
lizmat looks 13:54
jnthn It looks like it's just returning the closure that, when invoked, puns the role and dispatches
lizmat garbage in the sense that if you call what you got returned, it segfaults
m: dd buf8.^find_method("read-int8")(blob8.new(255),0) 13:55
camelia (signal SEGV)
jnthn Yeah, OK, so that adds nothing useful :)
I note that this is a really odd thing to be doing in general 13:56
lizmat changed the title
dogbert2_ ==16438== Invalid read of size 1 ==16438== at 0x40303F0: __memcpy_chk (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==16438== by 0x4151B37: memcpy (string3.h:51) ==16438== by 0x4151B37: read_buf (VMArray.c:903)
lizmat jnthn: yeah, it was for writing tests and iterating over read-int8, read-int16, etc.
dogbert2_ lizmat's bug ^^
jnthn dogbert2_: Yeah, already got that :) 13:57
lizmat now using buf8."$method"() syntax
dogbert2_ I suspected that might be the case :)
jnthn Thing is, we're taking a role, and then passing something other than that role as the invocant
lizmat jnthn: if you think it's a DIHWIDT case, then that's fine by me :-) 13:58
jnthn Well, it shouldn't SEGV
So I want to at least fix that
ah, yes 13:59
-> $inv, *@pos, *%named {
$!pun."$name"(|@pos, |%named)
}
This is the closure it returns
Notice that it dscards $inv
So it's punning it and then making the call on the type object produced by the punning
And I get the new ops fail to check their input IS_CONCRETE 14:00
I think using .^find_method and then feeding in a different invocant is a breach of protocol 14:01
So it's quite reasonable for it not to work out
m: blob8.read-int8(0)
camelia (signal SEGV)
jnthn But the bug basically golfs to that
jnthn updated the ticket 14:07
lizmat concreteness check added with github.com/rakudo/rakudo/commit/fecfb22d70 14:40
tests added with github.com/perl6/roast/commit/88a20c74f3
timotimo now that AT-POS and friends on native arrays have bounds checks, we might want to start looking into value domain analysis or whatever that's called 16:34
to find locals that never have negative numbers in them 16:35
or, you know, ask people to use unsigned ints and make that faster :D
nine Darn....I used an uint for the offset argument to the (read|write)(u?int|num) ops. And changing that now really breaks nqp's build 19:29
nine Of course I can just disable the bytecode validator, rebootstrap and re-enable the validator... 19:31
Geth MoarVM: 1343702c3f | (Stefan Seifert)++ | src/core/interp.c
Fix segfault on (read|write)u?int on a type object
 19:45
MoarVM: 7df8596ebe | (Stefan Seifert)++ | 5 files
Correctly handle negative offsets in (read|write)(u?int|num) ops

Other array ops treat negative indices as counting from the end of the array. Do the same for the bytestream handling ops.
travis-ci MoarVM build errored. Stefan Seifert 'Correctly handle negative offsets in (read|write)(u?int|num) ops 20:05
travis-ci.org/MoarVM/MoarVM/builds/467678266 github.com/MoarVM/MoarVM/compare/6...f8596ebece

Powered by Cro and the Raku® Programming Language.

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

Thank you!