github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:07 sena_kun left 00:11 lucasb left 00:29 pamplemousse left
Geth MoarVM: b1bb93490b | (Timo Paulssen)++ | src/debug/debugserver.c
make debugserver errors/output clearer with "Debugserver:"
 00:55
MoarVM: 85ce8ecc15 | (Timo Paulssen)++ | src/debug/debugserver.c
if getaddrinfo in debugserver fails, get better error

on windows it used to fail because WSAStartup had been missing, and it lead to listensocket to become -1, but errno had been reset to "no error", leading to a silly error. Let's not have that again in the future for any reason
02:37 pamplemousse joined 03:18 klapperl left 03:21 klapperl joined 03:35 AlexDaniel joined 03:44 pamplemousse left 03:49 pamplemousse joined 04:56 pamplemousse left 06:42 domidumont joined 06:49 domidumont left 06:58 patrickb joined
nine .tell samcv definitely candidates for the point release: github.com/MoarVM/MoarVM/commit/00...abcfb2f4a8 and github.com/MoarVM/MoarVM/commit/d8...f301fb71f1 07:01
yoleaux nine: I'll pass your message to samcv.
07:16 domidumont joined
nine The variable causing the "Adding pointer %p to past fromspace to GC worklist" error I came across yesterday seems to be updated_static_frames in the spesh worker: github.com/MoarVM/MoarVM/blob/mast...rker.c#L16 07:45
08:01 zakharyas joined
nine I can only assume that somewhere in a thread's startup there's still a place where a well timed GC of another thread may interfere 08:16
08:29 AlexDaniel left 09:05 sena_kun joined 09:46 robertle joined 10:09 AlexDaniel` left 10:37 MasterDuke left 10:50 AlexDaniel` joined 11:15 zakharyas left 11:26 Guest37021 joined 12:47 zakharyas joined 12:49 sena_kun left, sena_kun joined 12:58 Voldenet left 13:03 Voldenet joined, Voldenet left, Voldenet joined 13:25 pamplemousse joined 13:29 Altai-man_ joined 13:30 sena_kun left 13:35 Altai-man_ left
Guest37021 I did a spectest run with nine's fixes and a small nursery. Two scripts failed with GC related errors 13:38
t/spec/S32-io/out-buffering.t and t/spec/S32-io/socket-recv-vs-read.t
the first script panics here: #1 0x00007ffff74f32b3 in MVM_gc_root_add_temps_to_worklist (tc=0x555555758cc0, worklist=0x555556f52910, snapshot=0x0) at src/gc/roots.c:272 13:39
the second script fails like this 13:46
#1 0x00007ffff75222fe in push (tc=0x555558bba440, st=0x5555557d1340, root=0x7fffe4001590, data=0x7fffe40015a8, value=..., kind=8) at src/6model/reprs/VMArray.c:480
#2 0x00007ffff751934d in MVM_repr_push_o (tc=0x555558bba440, obj=0x7fffe4001590, pushee=0x55555575cfe0) at src/6model/reprconv.c:387
#3 0x00007ffff75118bd in listen_setup (tc=0x555558bba440, loop=0x555558ab4750, async_task=0x55555575d070, data=0x5555576458e0) at src/io/asyncsocket.c:801 13:50
nine: do you see anything suspicious here - gist.github.com/dogbert17/2cd3ea8d...8e943ffdf0 13:55
jnthn: are you making any progress on your PerlCon prep ? 13:58
14:06 lucasb joined
nine Guest37021: I'd guess another missing MVMROOT 14:53
Guest37021 nine: thx, it seems to complain about the parameter 'pushee' which can be glimpsed here: 15:26
#2 0x00007ffff751934d in MVM_repr_push_o (tc=0x555558bba440, obj=0x7fffe4001590, pushee=0x55555575cfe0) at src/6model/reprconv.c:387
MoarVM panic: Collectable 0x55555575cfe0 in fromspace accessed 15:27
15:43 robertle left 15:45 patrickb left 15:54 patrickb joined 15:55 discord6 left, discord6 joined, discord6 left, discord6 joined 15:59 discord6 left 16:00 discord6 joined 16:20 domidumont left
Geth MoarVM: bf3c6a97d6 | MasterDuke17++ (committed using GitHub Web editor) | src/io/procops.c
Fix warning about directive in format string
 17:05
17:26 AlexDaniel joined 17:30 MasterDuke joined 18:13 pamplemousse left 18:16 chloekek joined 18:20 zakharyas left
dogbert17 does anyone know if MVM_repr_alloc_init can cause a GC? github.com/MoarVM/MoarVM/blob/mast...conv.c#L16 18:29
timotimo allocate would definitely do that 18:30
18:31 pamplemousse joined
timotimo and since the initialize function call is wrapped in MVMROOT, we're at least expecting it to be a possibility for that to cause GC 18:31
dogbert17 I'm trying to debug a MoarVM Panic - Collectable %p in fromspace accessed
I have found the following so far
timotimo does it have anything to do with profiling or debugserver or anything else with instrumentation?
dogbert17 no, just a small nursery 18:32
the object pushed on this line is what the panic complains about - github.com/MoarVM/MoarVM/blob/mast...ket.c#L801
timotimo ah, so the repr_alloc_init there could have caused GC and that could have moved body.schedulee around? 18:33
no
async_task would be the one that'd move
earlier in the code, async_task is already rooted, and later in the code as well 18:34
dogbert17 all I can say is if I put this on line 800 - MVM_ASSERT_NOT_FROMSPACE(tc, ((MVMAsyncTask *)async_task)->body.schedulee); it will panic there
timotimo so that makes a lot of sense
that it'd need a rooting earlier there
dogbert17 if I put MVM_ASSERT_NOT_FROMSPACE(tc, ((MVMAsyncTask *)async_task)->body.schedulee); in the beginning of the function 'listen_setup' it wont trigger at that location 18:35
i.e. areound line 760
timotimo i wrote the code that's wrong
wouldn't you know it
dogbert17 cool, do you see a fix in front of you :) 18:36
timotimo yeah 18:37
dogbert17 ++timotimo 18:38
Geth MoarVM: 57a6d475b1 | (Timo Paulssen)++ | src/io/asyncsocket.c
Add a missing gc root for asyncsocket listen setup
 18:39
dogbert17 that was quick
timotimo you made it easy 18:40
dogbert17 will give it a whirl
timotimo did the point release already happen? this is a candidate to be cherry-picked to the release branch, too 18:41
dogbert17 I don't think it's out yet 18:42
timotimo yeah, samcv, could this commit 57a6d475b1 also make it in?
dogbert17 ha, now it failed at a totally different location 18:43
timotimo damn, we haven't fixed every bug yet? :(
dogbert17 #1 0x00007ffff75cedb7 in MVM_gc_root_add_temps_to_worklist (tc=tc@entry=0x69aef0, worklist=worklist@entry=0xa56330, snapshot=snapshot@entry=0x0) at src/gc/roots.c:272 18:44
#2 0x00007ffff75d15f5 in MVM_gc_collect (tc=0x69aef0, what_to_do=<optimized out>, gen=gen@entry=0 '\000') at src/gc/collect.c:145
timotimo oh, damn
add_temps_to_worklist means something that has been rooted was already wrong at that point, perhaps?!
dogbert17 I have seen that when running another file 18:45
timotimo hey, can you put a pointer check thingie into MVM_gc_root_temp_push or what it's called?
dogbert17 I guess I can
timotimo the rest of that stack trace would be interesting, too 18:46
dogbert17 you mean MVM_gc_root_add_temps_to_worklist right?
timotimo yeah 18:47
no
sorry
dogbert17 oops
timotimo er, the rest of that stack trace i mean
dogbert17 ah, sec
timotimo the rest of the stacktrace that ends in add_temps_to_worklist
but the pointer check would go into whatever MVMROOT uses
MVM_gc_root_temp_push is the name
dogbert17 gist.github.com/dogbert17/cc3723e9...aa4be2f61f 18:48
note that optimization was turned on
timotimo oh? capturelex? frame_move_to_heap?
that doesn't bode well
dogbert17 uh oh 18:49
cool, there is a #define MVM_TEMP_ROOT_DEBUG 0 flag that I could try using 18:51
timotimo cool
dogbert17 running but so far nothing. these bugs are quite elusive 18:53
19:19 patrickb left, klapperl left 19:25 klapperl joined 19:30 MasterDuke left 19:40 robertle joined 19:45 pamplemousse left
samcv timotimo, so the two nine said and the one you mentioned? 19:57
yoleaux 07:01Z <nine> samcv: definitely candidates for the point release: github.com/MoarVM/MoarVM/commit/00...abcfb2f4a8 and github.com/MoarVM/MoarVM/commit/d8...f301fb71f1
20:12 patrickb joined 20:25 lucasb left 20:36 robertle left 20:46 pamplemousse joined 21:03 chloekek left
AlexDaniel samcv: fyi I changed the release branch from “2019.07.1” to “release-2019.07.1” 21:51
samcv: this way we avoid collision with the upcoming tag
21:58 brrt joined 22:04 patrickb left
brrt \o 22:24
22:32 pamplemousse left
timotimo o/ 22:35
brrt ohai timotimo 22:55
nine++ , have a great day tomorrow
23:08 brrt left 23:56 pamplemousse 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!