github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
travis-ci MoarVM build failed. Altai-man 'Merge pull request #1253 from MoarVM/2020.02.1-release 03:12
travis-ci.com/tbrowder/MoarVM/builds/151290341 github.com/tbrowder/MoarVM/compare...7317dd3a06
lizmat and yet another Rakudo Weekly hits the Net: rakudoweekly.blog/2020/03/02/2020-...ubenreuth/ 10:37
Guest1277 is everyone suddenly hiding in Erlangen? 13:32
nwc10 not *yet* 13:33
leont NO :-( 13:36
timotimo i'm not going, sorry 14:27
(also, probably good since i'm rather a little sick right now)
Kaiepi can someone review github.com/MoarVM/MoarVM/pull/1240 ? it makes builds less annoying when libtommath/libuv/whatever get updated on openbsd 14:28
nine At work we've got a core dump caused by a segfault in MVMSpeshLog's gc_mark function. At first I thought there's no way to find and fix this without being able to reproduce (the app was running fine all week), but maybe there is. 14:50
The segfault occurs because log->entries[i].invoke.sf points to inaccessible memory, i.e. that thing was probably already freed. 14:51
There are only 2 threads running with the spesh thread running into that segfault while the other thread triggered the GC run from MVM_frame_move_to_heap 14:53
Oh, the static frame that's missing is actually the initial_invoke of the spesh thread itself! 14:54
#7 0x00007f797c0b326c in MVM_interp_run (tc=0x532, tc@entry=0x561d64379d10, initial_invoke=0x176ae800f8, invoke_data=0x7f79762150b0, invoke_data@entry=0x561d6437b0a0) at src/core/interp.c:162
Guest1277 nine: is sf = ShadowFacts? 15:05
nine static frame 15:08
Guest1277 aha
Guest1277 goes back into lurking mode 15:09
nine I think it's just coincidence that the address matches that of initial_invoke. After all that will have been GCed and the memory reused. 15:15
timotimo well that's super weird :) 15:17
nine Btw. for sure one of the lovliest systemd features: gist.github.com/niner/eeb3f329cb34...91fe4b9f93 15:58
Wait a minute... the segfault is in line 56 MVM_gc_worklist_add(tc, worklist, &(log->entries[i].invoke.sf)); 16:11
But: p log->entries[i]
$3 = {kind = 7, id = 341579, {entry = {sf = 0x176ae800f8, cs = 0x1b400000000}, param = {type = 0x176ae800f8, flags = 0, arg_idx = 436}, type = {type = 0x176ae800f8, flags = 0, bytecode_offset = 436}, value = {value = 0x176ae800f8, bytecode_offset = 0}, invoke = {sf = 0x176ae800f8, caller_is_outer = 0,
was_multi = 0, bytecode_offset = 436}, osr = {bytecode_offset = 1793589496}, plugin = {bytecode_offset = 1793589496, guard_index = 23}}} 16:12
The log entry has kind 7 which is MVM_SPESH_LOG_RETURN, not MVM_SPESH_LOG_INVOKE
How do we end up there?
timotimo i wonder if the call frame correlation id is valid? 16:15
m: say 341579.base(16)
evalable6 5364B
nine You mean the whole entry might be corrupted? 16:17
timotimo that doesn't really explain the odd source line position, though if you've got an optimized build, it could just be odd line annotations because of re-ordered code 16:18
i'm not skilled enough at asm reading to just go through the entire functino to figure out what's going on 16:19
nine Well from an assembly perspective, all the calls in that switch are actually identical, so the whole switch is superfluous. I guess the compiler is smart enough to notice this, too. 16:34
Which does make me wonder how it would be able to know which line number we're at exactly. My guess is: it just doesn't and takes the last one. 16:37
So it's really an inaccessible type in a spesh log. This has happened before. 16:38
nine I guess my only chance at this point is to look at the nearby spesh log entries in the hope that this will give some indication of where the faulty one may come from 17:14
vrurg Could be related to yours: "raku(35863,0x700009d55000) malloc: *** error for object 0x7fee7d18a800: pointer being realloc'd was not allocated" – Test::Mock threads.t fails with this regularly. 17:50
nine doesn't see a connection 17:54
japhb vrurg: See gist.github.com/japhb/8588c009de25...9cae15e905 and colabti.org/irclogger/irclogger_lo...02-28#l196 -- Test::Mock's tests appear to be discovering that something recent (post-2020.02) broke OO::Monitors. (Not as in "made it fail tests" but as in "made it stop preventing races".) 19:35
vrurg japhb: Can't get deeper into it, but to me it currently looks like something about moar. 19:36
vrurg japhb: First of all, it's the error I shown above. Also, would it be a problem with dispatching it would ruin the test totally because there is no room for flapping. 19:38
japhb vrurg: jnthn had been guessing that something in the dispatch changes broke the way that OO::Monitors does method wrapping to manage locks, so that it appears to work but doesn't actually prevent thread races. 19:40
(Or maybe OO::Monitors doesn't detect the way that it fails to wrap now, and thus thinks it has done the right thing when it really hasn't.)
vrurg japhb: BTW, blin found nothing about OO::Monitors. Anyway, the current implementation is buggy. The fix is awaiting for a MoarVM PR to merge. 19:41
japhb vrurg: Right, OO::Monitor's own tests *don't* detect it. But for some reason, it seems Test::Mock's tests *do* (because Test::Mock is implemented as a monitor). That said, of course you could have found an additional failure mode/cause. :-) 19:42
vrurg Could be. Too many factors for now. 19:45
Meanwhile, somebody: github.com/MoarVM/MoarVM/pull/1252, please! :)
My future talk on TPC might depend on this PR... 19:46
Geth MoarVM: 947ebfcb0c | (Vadim Belman)++ | 10 files
Add nextdispatcherfor/takenextdispatcher ops

Provide support for Raku chained dispatchers. Their purpose is to pass information to the downstream dispatcher about what upstream dispatcher must take over the control next when downstream exhausts.
For example, when one wraps a candidate in a multi, the `WrapDispatcher` must know about the instance of `MultiDispatcher` to switch back to it when all wrappers are done and the candidate calls one of
  {next|call}{same|with}.
MoarVM: 0b4bdeccbc | (Vadim Belman)++ | 6 files
Merge branch 'master' into rakudo_3499
19:47
MoarVM: a7fa6daadd | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 10 files
Merge pull request #1252 from vrurg/rakudo_3499

Add nextdispatcherfor/takenextdispatcher ops
lizmat vrurg: I assume you take care of the NQP bumping and stuff ?
vrurg lizmat++ Thanks alot! Sure, I will.
In any case, it's a chain of PRs.
vrurg is now away now. Making bookings for the trip to TPC. 19:49
MasterDuke it seems like maybe spesh logs aren't being freed up when run with --full-cleanup. how would that be done? 21:53
and/or spesh workers 21:56