[00:03] *** sena_kun joined [00:05] *** Altai-man_ left [00:19] *** Voldenet left [00:20] *** Voldenet joined [00:20] *** Voldenet left [00:20] *** Voldenet joined [02:02] *** Altai-man_ joined [02:04] *** sena_kun left [02:43] *** AlexDaniel left [02:45] *** AlexDaniel joined [02:45] *** AlexDaniel left [02:45] *** 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 [06:26] good *, #moarvm [06:30] *** brrt left [06:32] yo [07:18] *** zakharyas joined [07:45] *** squashable6 left [07:45] *** squashable6 joined [08:03] *** sena_kun joined [08:05] *** Altai-man_ left [08:25] *** leont joined [08:36] *** brrt joined [08:36] good * #moarvm [08:37] \o [09:14] *** brrt left [09:14] *** AlexDaniel left [09:17] *** AlexDani` joined [09:31] o/ [09:32] o/ [09:45] *** AlexDani` is now known as AlexDaniel [09:45] *** AlexDaniel left [09:45] *** 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 [14:16] is there any reason in particular we're not giving our threads "names"? [14:21] Not giving people more names to bikeshed? ;-) [14:21] But no, I don't think there's any deeper reason for it... [14:31] <[Coke]> ... what would we call them? "thread-1", "thread-2" ? [14:31] <[Coke]> :) [14:31] well at the very least there's the spesh thread [14:31] <[Coke]> I guess we could name the uv one. [14:32] <[Coke]> 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:55] oh, this is just for users / sysadmins looking at fifty "moar" processes/threads and wondering wtf is up with that [14:58] <[Coke]> h [14:58] <[Coke]> ah [15:10] * nine didn't know threads can have names [15:16] Is it actually an OS concept? I mean, I know on .Net and the JVM I get to pick names [15:18] int pthread_setname_np(pthread_t thread, const char *name); [15:19] ah, interesting [15:19] That makes it even more worth having [15:20] 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 [15:22] the prctl man page is pretty big [15:35] uv_set_process_title exists :) [15:36] oh, wait, that's not for individual threads i think [15:40] whoa, prctl allows you to redirect the /proc/pid/exe symlink to any file descriptor you've opened [15:42] 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 [15:43] since they tend to generate cpu load the entire time the program is running (after the first user-level thread has been started) [15:55] somehow it only works for the io loop thread, not for the spesh worker ?!? [15:58] the same line of code gives a "not declared" error for setname_np in worker.c but no error or warning in loop.c [16:00] ooh [16:00] "the thread name is a meaningful C language string, whose length is restricted to 16 characters" [16:00] means "if you pass something longer than 16 characters, it's a no-op", apparently [16:00] rather than "only the first 15 characters are actually used" [16:00] that's an odd choice, but at least i was just holding it wrong [16:01] https://cdn.discordapp.com/attachments/557618333755768832/730091242683367484/image.png [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 [17:40] *** AlexDaniel joined [17:40] *** AlexDaniel left [17:40] *** AlexDaniel joined [18:02] *** Altai-man_ joined [18:05] *** sena_kun left [18:34] *** MasterDuke joined [18:35] timotimo: that's cool. would those name be easily visible in gdb? [18:38] https://cdn.discordapp.com/attachments/557618333755768832/730130608810098759/image.png [18:38] MasterDuke ^ [18:38] nice! [18:38] push it [18:45] it's not portable and i've done nothing to make sure it doesn't break on other system [18:49] ¦ MoarVM/give-threads-names: 9a9ca43493 | (Timo Paulssen)++ | src/spesh/optimize.c [18:49] ¦ MoarVM/give-threads-names: propagate facts in set elimination in one more case [18:49] ¦ MoarVM/give-threads-names: review: https://github.com/MoarVM/MoarVM/commit/9a9ca43493 [18:49] ¦ MoarVM/give-threads-names: af5b89b64b | (Timo Paulssen)++ | src/spesh/inline.c [18:49] ¦ MoarVM/give-threads-names: when turning return to box in inline, give known type flag [18:49] ¦ MoarVM/give-threads-names: review: https://github.com/MoarVM/MoarVM/commit/af5b89b64b [18:49] ¦ MoarVM/give-threads-names: f4aa9728ee | (Timo Paulssen)++ | 2 files [18:49] ¦ MoarVM/give-threads-names: give io loop thread and spesh thread a name [18:49] ¦ MoarVM/give-threads-names: [18:49] ¦ MoarVM/give-threads-names: continuous integration shall help me figure out how to [18:49] ¦ MoarVM/give-threads-names: make this not explode on non-gnu systems [18:49] ¦ MoarVM/give-threads-names: review: https://github.com/MoarVM/MoarVM/commit/f4aa9728ee [18:49] oh there were some other commits in there as well [18:50] ¦ MoarVM: timo++ created pull request #1325: Give threads names [18:50] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1325 [18:57] https://dev.azure.com/MoarVM/MoarVM/_build/results?buildId=69&view=logs&j=bfe96415-bac8-5ed9-337c-3aa47377474c&t=4e307162-6b12-59a0-a35d-3a6eccc3eedf&l=101 - well, that's a weird way to put that [19:00] 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? :\ [19:05] 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! [19:06] you throw a specially formatted exception [19:06] and the debugger catches it and gets the name from it [19:15] 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 [19:15] but forcing nativecall into the core sounds slightly unwise :) [19:15] * lizmat wonders what would be against that ? [19:16] I know it used to be an ecosystem module, now a core module [19:16] 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 [19:16] well, perhaps newdisp will fix that ? [19:17] dispatch is new in new-disp [19:18] it's the new shiny that i should keep myself from just immediately jumping onto with everything i can come up with [19:19] ¦ MoarVM/give-threads-names: 7369407e03 | (Timo Paulssen)++ | 2 files [19:19] ¦ MoarVM/give-threads-names: let's see if this code taken from stackoverflow is right [19:19] ¦ MoarVM/give-threads-names: review: https://github.com/MoarVM/MoarVM/commit/7369407e03 [19:22] *** vrurg left [19:37] 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:42] *** vrurg joined [19:49] evil GC, moving my objects :-) [19:49] *** zakharyas joined [20:04] *** sena_kun joined [20:04] *** Altai-man_ left [20:07] .oO( have GC, will travel ) [20:07] yep [20:08] 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 [20:52] 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. [20:52] With unicode being so complicated and NFG turning it up to 11, I was sure I'd find something. [20:52] However, I hammered encode(), decode(), and decodestream() for every encoding MVM supports, [20:52] and the biggest finding is that I need new hardware. [20:53] 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. [20:53] There are a few bits of code that the fuzzer never reached, and looking at those is on my todo list. [20:53] 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. [20:54] ;- [20:54] oops [20:54] :-) to the bit about "new hardware" [20:54] and what follows is good to hear [20:55] 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 [20:55] yeah I was impressed. I thought there would be an off-by-1 or use after free somewhere [21:05] samcv ^^ [21:05] and jnthn I assume ? [21:35] cool, thanks for the work discoD [21:40] no problem. it was a fun challenge getting everything setup and working at reasonable speeds [21:41] i picked string handling to start because that's where good programmers go to write exploitable code [21:41] :-) [21:42] 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:54] 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 :) [21:55] sure. I think getting it into google's OSS fuzz program would be a good goal once there are enough tests [21:56] 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 [21:56] yeah, all my harnesses use libmoar only [21:57] AFL uses it's own "fork server" to deal with just that [21:57] i've fuzzed moar bytecode before, which didn't require much code to be run [21:58] 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:59] 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 [21:59] and libuv does things to stdin, stdout, stderr [22:01] we can rip out the entirety of stdio :D [22:01] for reference, i was getting a few thousand tests/second using the delayed fork method, so it's not too bad [22:02] that included tearing down the vm after every fork to make the GC work [22:02] 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 [22:06] 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:36] *** AlexDaniel left [22:48] *** tbrowder left [22:50] samcv++ did the most recent work in that area, but I suspect an amount of my original work there survives too :) [22:50] *** kawaii left [22:50] discoD++ for trying to break it [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