github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:15 lizmat left 02:26 Kaiepi left, Kaiepi joined 02:27 p6bannerbot sets mode: +v Kaiepi 07:14 domidumont joined, p6bannerbot sets mode: +v domidumont 07:35 xlat joined 07:36 p6bannerbot sets mode: +v xlat 07:44 robertle joined 07:45 p6bannerbot sets mode: +v robertle
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
07:58 robertle left 07:59 robertle joined 08:00 p6bannerbot sets mode: +v robertle 08:32 robertle left 08:41 zakharyas joined 08:42 p6bannerbot sets mode: +v zakharyas, xlatd7 joined 08:43 p6bannerbot sets mode: +v xlatd7 08:46 xlat left 08:49 robertle joined 08:50 p6bannerbot sets mode: +v robertle 08:55 zakharyas left 08:56 zakharyas joined 08:57 p6bannerbot sets mode: +v zakharyas 09:07 lizmat joined, p6bannerbot sets mode: +v lizmat 09:11 nop1 joined 09:12 p6bannerbot sets mode: +v nop1 09:13 zakharyas left 09:15 xlatd7 left
jnthn morning o/ 09:42
nwc10 \o 09:43
jnthn: ASAN found your most recent changes to be very boring 09:44
09:44 xlatd7 joined
lizmat morning * 09:44
09:44 nop1 left, p6bannerbot sets mode: +v xlatd7
jnthn likes keeping ASAN bored 09:50
09:56 xlatd7 left
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
10:46 zakharyas joined 10:47 p6bannerbot sets mode: +v zakharyas
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
12:03 lucasb joined, p6bannerbot sets mode: +v lucasb 13:39 robertle left
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
15:10 zakharyas left 15:19 lizmat left 15:26 robertle joined 15:27 p6bannerbot sets mode: +v robertle 16:13 synopsebot joined 16:14 p6bannerbot sets mode: +v synopsebot 16:25 domidumont left 16:26 sivoais joined, p6bannerbot sets mode: +v sivoais 16:34 dogbert11 left
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
18:19 zakharyas joined 18:20 p6bannerbot sets mode: +v zakharyas 18:38 domidumont joined, p6bannerbot sets mode: +v domidumont 19:25 domidumont left
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
19:29 zakharyas left
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.
20:05 travis-ci joined, p6bannerbot sets mode: +v travis-ci
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
20:05 travis-ci left 20:11 robertle left 20:35 zakharyas joined 20:36 p6bannerbot sets mode: +v zakharyas 21:46 zakharyas left

Powered by Cro and the Raku® Programming Language.

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

Thank you!