🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
timo oh that was the 2025.02 version where i did get that segfault ... kind of not what i was hoping for 00:06
02:30 nine left, nine joined 03:26 ShimmerFairy left, ShimmerFairy joined 04:18 [Coke] joined
Geth setup-raku/dependabot/npm_and_yarn/picomatch-4.0.4: 44560efc04 | dependabot[bot]++ (committed using GitHub Web editor) | package-lock.json
Bump picomatch from 4.0.3 to 4.0.4

Bumps [picomatch](github.com/micromatch/picomatch) from 4.0.3 to 4.0.4.
  - [Release notes](github.com/micromatch/picomatch/releases)
  - [Changelog](github.com/micromatch/picomatch/bl...NGELOG.md)
  - [Commits](github.com/micromatch/picomatch/co...3...4.0.4)
... (8 more lines)		 06:28
setup-raku: dependabot[bot]++ created pull request #50:
Bump picomatch from 4.0.3 to 4.0.4
disbot2 <melezhik.> I tried that , it did not reproduce segfault 06:58
<melezhik.> Nope. Only saw it on 2025.02 version
releasable6 Next release in ≈2 days and ≈11 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
08:47 librasteve_ joined
disbot2 <melezhik.> Ок. So I run tests against 2026.02 yesterday and today no crash so far. One user who used to have one or two crashes yesterday told me all further tests passes since then, but another users told that after several successful tests he again received segfault , they also use 2026.02I know maybe this all sounds abit vague and not solid and probably we just need more tests / time to get certain statistics . So do you plan to run test again debug 09:10
enabled Rakudo , right ? It this is head Rakudo I am afraid we might not reproduce the issue, but at least we can ask those users to use this version in their environments, right ?
09:38 nine left, camelia left 10:07 nine joined 10:12 nine left
timo the debug enabled rakudo i linked to in the issue is based on the 2026.02 tag for all three components. without debug symbols we would have severe difficulties trying to find out what's going wrong :( 10:14
it's possible that something in the build environment changed between when nxadm built the packages and when i did, but i would assume the universal build image version 9 changes really really really slowly, if at all 10:17
disbot2 <melezhik.> Ok . Managed to reproduce on 2026.02 10:18
<melezhik.> github.com/rakudo/rakudo/issues/60...4133347190 10:19
timo i ran `raku-m -MSparrow6::DSL sparrowfile` in a loop for a while and the only issue i could get was that qemu itself segfaulted, probably as a result of me running a loop of "killall qemu-kvm" in a terminal on the side so it would actually stop 10:20
i was still not able to find out why the F it would always generate truncated core dumps 10:21
disbot2 <melezhik.> 3,out 22 tests failed with segfault . Those tests are very similar to what we did they just not only bootstrap qemu but boot again and run sum sparrow scenarios on it via ssh , but crash usually happens in bootstrap step
<melezhik.> And also every crashed report has this bad none utf8 symbols just before segfault message , if you look it at gh issue 10:22
timo anyway, I have to do dayjob work now
disbot2 <melezhik.> Overall it took 3 hours to complete . But i feel quite satisfied I managed to reproduce it, it just takes more time and more or less correlates with experience of others users 10:23
<melezhik.> That’s fine . No rush
<melezhik.> I can probably download debug version and run tests with it 10:24
timo oh i thought you were already reproducing it with the debug version
disbot2 <melezhik.> No . It was regular version 10:25
<melezhik.> I just wanted to make it sure it’s reproducible at all )
timo yes, that is indeed an important step 10:26
disbot2 <melezhik.> I guess something subtle needs to happen to trigger the bad things it’s just for some reasons on old Rakudo its happens faster . Anyways we now one step probably closer in solving the mystery … I am going to run with debug Rakudo now )) 10:28
<melezhik.> Should I use raku or raku-debug ? 10:38
timo not raku-debug, that's something else
disbot2 <melezhik.> gist.github.com/melezhik/65cedc1f1...40d597244d 10:39
<melezhik.> Ok
<melezhik.> Asking just in case , so just raku?
timo yeah 10:40
disbot2 <melezhik.> Ok
<melezhik.> Will add installation log to ^^ this gist 10:41
<melezhik.> Oh , that for sure debug version zef install is so verbose )) 10:42
<melezhik.> Ok installed . Scheduled 30 full tests in queue ))) 10:50
<melezhik.> Will check in few hours our crashes ha ha 😆 10:51
11:43 nine joined
[Coke] releasable6: next 12:18
releasable6 [Coke], Next release in ≈2 days and ≈6 hours. There are no known blockers. 37 out of 47 commits logged
[Coke], Details: gist.github.com/2ba567cfe0bcef2ec2...3a10e882c1
12:35 camelia joined
[Coke] releasable6: next 12:43
releasable6 [Coke], Next release in ≈2 days and ≈6 hours. There are no known blockers. 40 out of 47 commits logged
[Coke], Details: gist.github.com/c14d04067db0e386aa...ccc175cddc
[Coke] releasable6: next 12:45
releasable6 [Coke], Next release in ≈2 days and ≈6 hours. There are no known blockers. 45 out of 47 commits logged
[Coke], Details: gist.github.com/fadd4ddc1803933b21...2aac4ac331
disbot2 <melezhik.> If there is any difference between Rakudo debug version and vanilla 2026.02 in terms of this issue . So my tests run 2 hours , all passes so far … 13:11
<melezhik.> Changed my nick name 13:12
<melezhik.> Oops it did not work apparently) 13:49
timo maybe the raku irc bridge bot caches the display names for a while? 16:25
disbot2 <melezhik.> No worries. I am going to use two nicknames ) this one and sp1983 ) 16:28
timo something that one could try to reproduce the issue better is to use `rr` to record execution, because rr has a "chaos mode" that tries to randomize parameters of the execution (like number of threads, and how scheduling behaves) in order to help hitting rare issues, but some of the dependencies of rr aren't packaged in rocky linux so I gave up trying to compile it after a short while 16:30
but even with a full recording of the crash, without debug symbols it'll still be difficult to figure out what actually really happened 16:31
much easier to at least get a thread's TC by reverse per-instruction stepping until the function entry and grabbing the register for the first argument 16:32
16:38 lizmat left 16:50 lizmat joined 16:55 sp1983 joined
sp1983 timo: gist.github.com/melezhik/65cedc1f1...nt-6052683 these are results for rakudo with debug enabled 16:56
for some reasons dumpctl info still shows truncated - "Thu 2026-03-26 16:25:45 UTC 162131 1001 1001 SIGSEGV truncated /opt/rakudo-pkg/bin/rakudo 18.3M" 16:57
maybe it's ok?
timo ok, we will want a gdb attached to the process so we don't have to rely on the core dumping mechanism that keeps giving us core dumps with stuff missing
sp1983 what should I do from that point ?
timo you can try `coredumpctl gdb`, doing "bt" will probably tell you it can't get the backtrace because it couldn't access the memory 16:58
sp1983 process ended , how do you want to attach to it ?
and by the way this time we only have one segfault for much more tests ( around 40-50 I guess ) 16:59
timo yes. ugh. 17:00
sp1983 and also intersting that this time we also hit this codepoint out of bounds.
so only 2 failures for the last few hours of tests ...
timo we should be able to `gdb --args rakudo -MSparrow6::DSL sparrowfile` and just do `run` every time it has finished. you can even get that to happen automatically 17:01
should I try rocky 9 instead of 10 to reproduce locally with rakudo-2026.02-with-debug-symbols?
sp1983 you may ... but in my case the issue is only reproduced after running too many tests and sometimes waiting hours ... 17:02
timo i'm going to try another way to get qemu out of the picture so things can be less slow to reproduce
sp1983 yeah
if you know how, that's be cool
I still think it's somehow relates to broken utf8 things making rakudo crash sometimes with utf8-c encoding ... 17:03
but I may be wrong
timo wow, how does rocky not have htop in its repos? wild ...
17:08 sp1983 left
disbot2 <melezhik.> )) 17:14
<melezhik.> You can add epel repo I guess 17:15
17:20 sp1983 joined 17:24 sp1983 left
timo oh the epel-release-* package is literally available right from the start, cool 17:32
20:59 librasteve_ left 22:14 Geth__ joined, evalable6__ joined, releasable6__ joined 22:17 RakuIRCLogger left, Geth left, evalable6 left, releasable6 left, samebchase left, samebchase9 is now known as samebchase

Powered by Cro and the Raku® Programming Language.

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

Thank you!