brrt good * #moarvm 06:05
nwc10 good *, #moarvm 06:35
jnthn: ASAN failures in spectests: paste.scsys.co.uk/565169
#0 0x7fa46a6c2285 in MVM_fixed_size_free src/core/fixedsizealloc.c:271 06:36
#1 0x7fa46a7de103 in gc_free src/6model/reprs/NFA.c:51
during GC
I have built with #define FSA_SIZE_DEBUG 1
but I don't think that that's needed to trigger this 06:37
dogbert2 good * #moarvm 09:14
building the core setting with a small nursery is, at least currently, a bad idea
Stage start : 0.000
Stage parse : MoarVM panic: Collectable 0x407a8f30 in fromspace accessed 09:15
brrt hmmm 10:08
that's interesting
dogbert2 brrt: perhaps I should try to figure out where that happens 10:16
brrt yeah, that seems legit :-) 10:18
jnthn timotimo: 3059ba2829 and paste.scsys.co.uk/565169 look related 10:28
timotimo oh? uh oh. let's see. 10:37
oh, facepalm 10:43
i somehow missed to change calloc into the corresponding function
i wasn't able to get asan to complain before, but the fix i made is Obviously Correct™ 10:49
Geth MoarVM: 054ad4e1d6 | (Timo Paulssen)++ | src/6model/reprs/NFA.c
convert left-over calloc to FSA equivalents
timotimo nwc10: would be cool if you tried again with this commit
nwc10 had already started 10:50
timotimo nice :)
dogbert2: try recompiling?
nwc10 only 5 seconds ahead of you :-)
(you asking, that is. had seen your approximate "d'oh" comment and assumed that a commit was about to land)
timotimo :) 10:52
dogbert2 timotimo: don't think it's the same problem since I wasn't using your commit from yesterday :) 10:53
timotimo oh, well :)
dogbert2 tries to catch the problem with gdb ... 10:54
and ... it turns out that the backtrace is in fact the very same as github.com/MoarVM/MoarVM/issues/707 10:55
notices that I had forgot to 'p MVM_dump_backtrace' in the bug report, here's a more complete version gist.github.com/dogbert17/2e270d08...5e9cb88631 10:59
timotimo fun! creating an accessor. that's right next to what liz was building for buildall :) 11:00
dogbert2 could there be a connection 11:01
timotimo probably not
lizmat oO( all problems are the same ) 11:06
timotimo problemly not 11:09
nwc10 ASAN has gone back to sleep 13:35
cognominal should not getaddrinfo() be within a MVM_gc_mark_thread_blocked/unblocked pair cuz it potentially blocks if the address is not yet cached ? github.com/MoarVM/MoarVM/blob/mast...ket.c#L305 15:21
timotimo ah, i didn't know about that 15:40
if you put blocked/unblocked, it'll have to be much more careful with regards to MVMROOT
jnthn Probably, yes
But check all its callers
That also
Every caller will need to be audited 15:41
cognominal I understand the purpose of VMROOT but I don´t know exactly yet what should go there 15:44
timotimo every variable that points to a GC-managed thing must go there 16:08
cognominal submitted it as an issue github.com/MoarVM/MoarVM/issues/708 16:16
timotimo how long can this block? worst case? 16:30
ilmari for as long as your DNS server takes to respond?
(or the resolver library times out)
cognominal the best way to (not) address the problem is to use the libuv asynchroneous getaddrinfo instead :) I noticed this bug when studying what this involved 16:33
timotimo oh, getaddrinfo 16:36
for some reason i was thinking of getpeername thing
ugexe with uv_getaddrinfo a NULL uv_getaddrinfo_cb to run synchronously might make it easy to use in syncsocket too 16:46
samcv good morning. 16:47
samcv yawns
lizmat \o samcv 16:48
samcv MasterDuke, made some comments on your join PR 20:09

Powered by Cro and the Raku® Programming Language.

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

Thank you!