github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Kaiepi sorry for the late response, i'll take a look later dogbert17 10:09
Guest13443 Kaiepi: it could be that you're totally innocent :-) dogbert17 in $work disguise 10:18
Kaiepi i'm 99% sure i'm responsible here, that pullreq of mine that got merged last week changed a lot with how async sockets deal with gc 10:19
Guest13443 it was the test file name which made me believe that you might be interested
nine Considering that it's probably a recent regression and there wasn't much else going on, it looks like a good bet 10:29
Guest13443 nine: can you see, given the gist what might be wrong? gist.github.com/dogbert17/26d3e358...e163246bc7 10:49
it's the parameter pushee in MVM_repr_push_o (tc=0x2fe35c0, obj=0x35e3a50, pushee=0x605c08) at src/6model/reprconv.c:387 which is busted 10:50
nine Guest13443: no, that backtrace alone is not enough. But it's a good start! It's pretty clear that the t->body.schedulee pointer is out of date. Since do_setup_setup seems to correctly MVMROOT t in the appropriate place, there must be a missing MVMROOT earlier in the program flow 13:23
So I'd look at the places where t->body.schedulee gets set and if there's allocation happening around that 13:24
nine read_setup looks fishy. Looks to me like MVM_io_eventloop_add_active_work can allocate. Would need to MVMROOT t there 14:06
Guest13443 nine: interesting, will have to investigate 14:11
timotimo making more stuff middle-mouse-button-clickable in moarperf
nine src/io/asyncsocketudp.c:296 also looks suspicious. This may allocate but we use both t and arr later on 14:12
same in line 299
Guest13443 is rooting a cheap operation? 14:15
timotimo yes
Guest13443 now that was a quick reply, timotimo++ 14:16
timotimo it's just a push into an array
nine Much cheaper than random failures anyway ;)
Guest13443 indeed
Guest13443 hello MasterDuke 14:40
any news wrt gist.github.com/dogbert17/e4cb7b4d...73a49c7727 14:43
timotimo finally, when moarperf is calculating reverse references or the BFS graph, there's a progress display for it 15:46
MasterDuke Guest13443: not really. there's a solution, but it involves repeating at `free()` in every branch of a sequence of if/elsif. otherwise i need some help wrt casting `MVMGrapheme32 *` to `char *` 15:51
lizmat and the last Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2019/10/15/...wineskins/ 16:48
dogbert17 .seen Kaiepi 21:25
tellable6 dogbert17, I saw Kaiepi 2019-10-15T10:19:07Z in #moarvm: <Kaiepi> i'm 99% sure i'm responsible here, that pullreq of mine that got merged last week changed a lot with how async sockets deal with gc
dogbert17 Kaiepi: stupid question but is this line correct? github.com/MoarVM/MoarVM/blob/mast...udp.c#L559 21:26
Kaiepi should be, that's how it loops through the list of addresses 21:28
dogbert17 ok, it seems as if the fromspace error occurs the second time line 573, in do_setup_setup, is run 21:35
Kaiepi if that happens the way the roots are laid out there something similar might also happen with parts of the async tcp socket code 21:42
dogbert17 I was wrong the problem occurs the third time do_setup_setup runs 21:54

Powered by Cro and the Raku® Programming Language.

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

Thank you!