github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:03 sena_kun joined 00:05 Altai-man_ left 00:19 Voldenet left 00:20 Voldenet joined, Voldenet left, Voldenet joined 02:02 Altai-man_ joined 02:04 sena_kun left 02:43 AlexDaniel left 02:45 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 02:55 MasterDuke left 03:29 Kaiepi joined 04:03 sena_kun joined 04:05 Altai-man_ left 05:01 nebuchadnezzar joined 06:00 brrt joined 06:02 Altai-man_ joined 06:04 sena_kun left
nwc10 good *, #moarvm 06:26
06:30 brrt left
timotimo yo 06:32
07:18 zakharyas joined 07:45 squashable6 left, squashable6 joined 08:03 sena_kun joined 08:05 Altai-man_ left 08:25 leont joined 08:36 brrt joined
brrt good * #moarvm 08:36
nwc10 \o 08:37
09:14 brrt left, AlexDaniel left 09:17 AlexDani` joined
jnthn o/ 09:31
lizmat o/ 09:32
09:45 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 10:02 Altai-man_ joined 10:05 sena_kun left 11:41 zakharyas left 12:03 sena_kun joined 12:05 Altai-man_ left 12:51 zakharyas joined 14:02 Altai-man_ joined 14:05 sena_kun left
timotimo is there any reason in particular we're not giving our threads "names"? 14:16
jnthn Not giving people more names to bikeshed? ;-) 14:21
But no, I don't think there's any deeper reason for it...
[Coke] ... what would we call them? "thread-1", "thread-2" ? 14:31
:)
timotimo well at the very least there's the spesh thread
[Coke] I guess we could name the uv one.
my take is that we're trying to keep threads as more low level constructs, so maybe we don't need to have a as "nice" an interface to interact with them. 14:32
timotimo oh, this is just for users / sysadmins looking at fifty "moar" processes/threads and wondering wtf is up with that 14:55
[Coke] h 14:58
ah
nine didn't know threads can have names 15:10
jnthn Is it actually an OS concept? I mean, I know on .Net and the JVM I get to pick names 15:16
timotimo int pthread_setname_np(pthread_t thread, const char *name); 15:18
jnthn ah, interesting 15:19
That makes it even more worth having
timotimo whoa, there is a "child subreaper" thing you can set with prctl 15:20
you can literally turn a thread/process to get orphaned children's-child processes reparented to it, rather than init
the prctl man page is pretty big 15:22
uv_set_process_title exists :) 15:35
oh, wait, that's not for individual threads i think 15:36
whoa, prctl allows you to redirect the /proc/pid/exe symlink to any file descriptor you've opened 15:40
also, i'm not sure what the nqp-level api should be (if we expose it at all) to give a thread a name 15:42
that'd be good at the very least for thread pool scheduler manager threads
since they tend to generate cpu load the entire time the program is running (after the first user-level thread has been started) 15:43
somehow it only works for the io loop thread, not for the spesh worker ?!? 15:55
the same line of code gives a "not declared" error for setname_np in worker.c but no error or warning in loop.c 15:58
ooh 16:00
"the thread name is a meaningful C language string, whose length is restricted to 16 characters"
means "if you pass something longer than 16 characters, it's a no-op", apparently
rather than "only the first 15 characters are actually used"
that's an odd choice, but at least i was just holding it wrong
raku-bridge <timotimo> cdn.discordapp.com/attachments/557.../image.png 16:01
16:03 sena_kun joined 16:05 Altai-man_ left 16:34 squashable6 left 16:36 squashable6 joined 17:23 zakharyas left 17:40 AlexDaniel left, AlexDaniel joined, AlexDaniel left, AlexDaniel joined 18:02 Altai-man_ joined 18:05 sena_kun left 18:34 MasterDuke joined
MasterDuke timotimo: that's cool. would those name be easily visible in gdb? 18:35
raku-bridge <timotimo> cdn.discordapp.com/attachments/557.../image.png 18:38
<timotimo> MasterDuke ^
MasterDuke nice!
push it
timotimo it's not portable and i've done nothing to make sure it doesn't break on other system 18:45
Geth MoarVM/give-threads-names: 9a9ca43493 | (Timo Paulssen)++ | src/spesh/optimize.c
propagate facts in set elimination in one more case
 18:49
MoarVM/give-threads-names: af5b89b64b | (Timo Paulssen)++ | src/spesh/inline.c
when turning return to box in inline, give known type flag
MoarVM/give-threads-names: f4aa9728ee | (Timo Paulssen)++ | 2 files
give io loop thread and spesh thread a name

continuous integration shall help me figure out how to make this not explode on non-gnu systems
timotimo oh there were some other commits in there as well
Geth MoarVM: timo++ created pull request #1325:
Give threads names		 18:50
timotimo dev.azure.com/MoarVM/MoarVM/_build...&l=101 - well, that's a weird way to put that 18:57
the man page says i'm supposed to set _GNU_SOURCE before including pthread to get it, but that's ... not really a way to find out if it's available 19:00
so do i have to build another piece of compilation + checking into configure? :\
oooh i know how to signal the thread name to moarvm from nqp/raku code 19:05
i'll do it just like it's done on windows!
you throw a specially formatted exception 19:06
and the debugger catches it and gets the name from it
yeah i can't really think of a good op to hook this functionality on to 19:15
in theory i could just nativecall it, tho
but forcing nativecall into the core sounds slightly unwise :)
lizmat wonders what would be against that ?
I know it used to be an ecosystem module, now a core module 19:16
timotimo dispatch could do it, since it can take a string for the operation name, but putting extremely-rarely-used things into the registered dispatch list could in theory add a conflict to the hash, making other dispatch calls ever so slightly slower
lizmat well, perhaps newdisp will fix that ?
timotimo dispatch is new in new-disp 19:17
it's the new shiny that i should keep myself from just immediately jumping onto with everything i can come up with 19:18
Geth MoarVM/give-threads-names: 7369407e03 | (Timo Paulssen)++ | 2 files
let's see if this code taken from stackoverflow is right
 19:19
19:22 vrurg left
timotimo this looks promising in terms of not breaking other systems, but i haven't tested if the thread names actually get set on the different linux builds there 19:37
19:42 vrurg joined
nwc10 evil GC, moving my objects :-) 19:49
19:49 zakharyas joined 20:04 sena_kun joined, Altai-man_ left
lizmat
.oO( have GC, will travel )
 20:07
nwc10 yep
if you refactor and inline a structure into the body of an MVMObject, you can't use its address as an ID for debugging. 20:08
Oops. :-)
20:36 zakharyas left 20:52 discoD joined
discoD It's been a while, but I was in here talking about fuzzing string decoders. 20:52
I wrote harnesses for AFL++, a fork of the coverage-guided AFL fuzzer, and some tooling to automate stuff.
With unicode being so complicated and NFG turning it up to 11, I was sure I'd find something.
However, I hammered encode(), decode(), and decodestream() for every encoding MVM supports,
and the biggest finding is that I need new hardware.
so a tip of the hat to whoever wrote all that. 20:53
There is at least one DOS in a coercion function, but I don't think normal raku code will ever reach it.
There are a few bits of code that the fuzzer never reached, and looking at those is on my todo list.
So, while all this is no proof of correctness, I will say that no one is going to own your raku web app via string decoders without significant effort.
nwc10 ;- 20:54
oops
:-) to the bit about "new hardware"
and what follows is good to hear
not that I had anmything to do with the NFG code (or much else for that matter) 20:55
thanks for trying to break it
discoD yeah I was impressed. I thought there would be an off-by-1 or use after free somewhere
lizmat samcv ^^ 21:05
and jnthn I assume ?
timotimo cool, thanks for the work discoD 21:35
discoD no problem. it was a fun challenge getting everything setup and working at reasonable speeds 21:40
i picked string handling to start because that's where good programmers go to write exploitable code 21:41
nwc10 :-)
discoD but if you've got suggestions for other areas of the vm to kick and prod at, i'd be happy to take a look 21:42
timotimo can you make the whole setup easily reproducible? whether it be containerisation via docker/podman or whatever? 21:54
also, tmaybe continuous fuzzing should become a thing :)
discoD sure. I think getting it into google's OSS fuzz program would be a good goal once there are enough tests 21:55
timotimo sadly, raku startup is slow enough to make fuzzing actual code really really hard 21:56
may be able to get some benefit from forking immediately before it reads the input program from stdin or so
discoD yeah, all my harnesses use libmoar only
AFL uses it's own "fork server" to deal with just that 21:57
timotimo i've fuzzed moar bytecode before, which didn't require much code to be run
discoD it also supports fuzzing without forking if you can guarantee that all state is reset. I've been unable to make that work with mvm 21:58
timotimo i just used the stage0 files from nqp, which some of them don't really have a mainline to speak of by themselves 21:59
aye, at the very least the unicode database setup is static and unresettable by default
and libuv does things to stdin, stdout, stderr
we can rip out the entirety of stdio :D 22:01
discoD for reference, i was getting a few thousand tests/second using the delayed fork method, so it's not too bad
that included tearing down the vm after every fork to make the GC work 22:02
timotimo i used to have afl's stats output up on hack.p6c.org to look at, but then that server caught on fire
22:02 Altai-man_ joined 22:05 sena_kun left
discoD i wrote a script to generate coverage reports based on AFL's test cases. There's another to run all the testcases through ASAN as well. i'll have a go at containerizing all of it. 22:06
22:36 AlexDaniel left 22:48 tbrowder left
jnthn samcv++ did the most recent work in that area, but I suspect an amount of my original work there survives too :) 22:50
22:50 kawaii left
jnthn discoD++ for trying to break it 22:50
22:52 SmokeMachine left 22:53 chansen_ left 23:27 lizmat left 23:43 Geth left 23:44 Geth joined 23:46 Geth left 23:47 Geth joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!