github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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.
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
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
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
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
Geth MoarVM: bf3c6a97d6 | MasterDuke17++ (committed using GitHub Web editor) | src/io/procops.c
Fix warning about directive in format string
 17:05
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
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
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
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
brrt \o 22:24
timotimo o/ 22:35
brrt ohai timotimo 22:55
nine++ , have a great day tomorrow

Powered by Cro and the Raku® Programming Language.

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

Thank you!