03:23 kjp left 03:24 kjp joined 13:06 librasteve_ joined
timo who would have thought that turning hash randomization off would get stability to 100% 13:23
lizmat heh... so we still have some hash gremlins in core building :-( 13:27
timo no
lizmat ah? then how do you explain the stability then ? 13:28
timo stability is about low-level control flow decisions inside the running process
lizmat ah, so you're not talking about reproducibility of the build, ok 13:29
timo correct, this is only about afl-fuzz
it uses the path takes through the program to decide if a change to the input file could be a candidate for finding new paths through the program
lizmat ack 13:30
timo which is how a coverage-guided fuzzer finds as many unique, different execution paths
if the same input run twice gives two different paths, it calls that "unstable" and it has a variety of drawbacks to try to fuzz something that isn't completely stable 13:31
in any case, i've run it for 12 hours with a 91% stable executable and it found no more crashes, now i'm running it with a 100.00% stable executable for 12 minutes already and, not really surprisingly, no crashes found either 13:32
ah, with 100.00% stability, the afl-tmin utility can also finally do something useful 13:34
it tries to shorten input files without changing the path and also replace different bytes with the same value without changing the path
so it reduces the test case to differences that "actually matter" and cuts down on "noise" 13:35
13:45 Geth left, Geth joined
timo if I implemented the same kind of coverage (i.e. compatible) for moar bytecode we could probably get better results from attempting to fuzz nqp and maybe even raku code, but it would still be terribly slow due to high startup time and slow compilation 14:28
github.com/ekiwi/custom-afl-instrumentation - this is a lot simpler than i thought, huh? 14:34
this is all a lot less complicated than I was thinking, but there's still some trickiness when you deal with code that was compiled dynamically; those would either have to not be instrumented for coverage at all, or get the same instrumentation if it's "the same" code, for some value of "same code" 14:54
ahead-of-time compilation has the benefit that it can just generate random numbers for everything it needs once at compile time and store it, then get the same value when running every time, no problem at all 14:55
but for dynamically compiled stuff there isn't a trivial "load it from disk"
Geth MoarVM/fix_buffer_overflow_in_utf8_c8_stream_decode: bc9431922f | (Timo Paulssen)++ | src/strings/utf8_c8.c
utf8-c8: don't write past end of result buffer
 18:15
MoarVM: timo++ created pull request #1994:
utf8-c8: don't write past end of result buffer in streaming decode		 18:16
timo [Coke]: here's the pull request
[Coke] And what is it fixing? How prevalent is this issue? 18:23
timo where-ever you streaming decode, which Proc::Async and prosumably async sockets use, with utf8-c8, your memory can get corrupted 18:28
[Coke] ok, that looks complicated enough of a change that I'm not comfortable squeezing it in. 18:30
and I don't think we've had any complaints about that particular issue just now, have we?
timo it's what melezhik has been complaining about
a change in Sparrow6 that made it use utf8-c8 to avoid dying when a process spits out binary (illegal binary or ansi escapes) caused segfaults on his machine and the machines of a few users of Sparrow6 18:31
Sparrow6 can use a work-around for now
[Coke] ok. I need another core developer to sign off on the PR. 18:33
lizmat fwiw /me doesn't feel confident enough
nine Masterduke ?
[Coke] Or, if the workaround is OK for now, we'll pull it immediately post-release. 18:34
the fact that there's a workaround makes me much happier.
timo and of course CI should be green (except for the typical failures that we already know of)
[Coke] 6 failing checks so far. 18:35
timo Sparrow6 could also use non-streaming decoding on every chunk of input it gets separately, which will give artifacts when a multi-byte utf8 character coincides with such a chunk boundary, but better than crashing and better than displaying text as a hex dump or something
[Coke] ah, but many passing? Not sure what's normal there.
timo right, we need to do something about the known failures, they are annoying 18:36
one of them is related to differences between gcc's and clang's interpretation of the x86_64 system5 ABI vis a vis what to do with upper bytes of a smaller-than-register function argument 18:38
that's a NativeCall test that's blowing up
there's one i haven't seen before, # Subtest: no SEGV with failed opens of MVM debug files 18:41
[Coke] OK - I'm at the point in the process where I have to do the MoarVM release.
I'll give you like 10 minutes to get someone to sign off. :)
timo hehe. 18:42
no it's okay, feel free to do the release immediately without the PR, [Coke] 18:45
Geth MoarVM/fix_buffer_overflow_in_utf8_c8_stream_decode: 886632dec5 | (Timo Paulssen)++ | src/strings/utf8_c8.c
utf8-c8: don't write past end of result buffer
 18:46
timo (^- just a rebase)
it looks like the built moarvm also crashes on windows for some fun reason 18:48
[Coke] O_o; 18:49
timo that didn't happen on the latest main branch commit 18:50
[Coke] patrickb: you seen any issues on moarvm on windows lately?
oh, main branch is OK, but PR is not?
timo correct 18:51
[Coke] ah, whew.
ok, PR out, onward with release.
timo I would never do that to you on release day
[Coke] ... crap. my release branch for moarm has modified 3rdparty files again. Need to add this to the release guide... 18:54
Geth MoarVM/main: 72618e4579 | (Will Coleda)++ | docs/release_guide.md
Save "clean 3rdparty/" notes for release mgr
 18:58
[Coke] feel free to note if there's a better way to do that. (seems to do the trick) 19:01
.... crap my GPG key expired 19:02
Geth MoarVM/2026.03: 4a000ed46b | (Will Coleda)++ | 2 files
Update changelog and version
 19:13
lizmat [Coke]++ 19:14
Geth MoarVM: coke++ created pull request #1995:
Update changelog and version		 19:17
MoarVM/main: 4a000ed46b | (Will Coleda)++ | 2 files
Update changelog and version
 19:33
MoarVM/main: cc91f7b195 | (Will Coleda)++ (committed using GitHub Web editor) | 2 files
Merge pull request #1995 from MoarVM/2026.03

Update changelog and version

Powered by Cro and the Raku® Programming Language.

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

Thank you!