00:07 colomon joined 00:20 colomon joined 01:47 ilbot3 joined 03:22 ShimmerFairy joined 03:42 lizmat_ joined 06:24 vendethiel joined 06:34 lizmat joined 06:39 FROGGS joined 07:05 virtualsue joined 07:55 kjs_ joined 07:59 virtualsue joined 08:00 _itz_ joined 08:42 kjs_ joined 08:52 zakharyas joined 08:58 Ven joined 08:59 FROGGS joined 09:08 lizmat joined 09:33 zakharyas joined 10:04 zakharyas joined 10:07 virtualsue joined 10:08 kjs_ joined 10:36 btyler_yapc joined 10:44 Ven joined
btyler_yapc hi folks. this is probably a more appropriate place than #perl6 to chat about a MVM segfault: gist.github.com/kanatohodets/66427...7c2616f6f2 (updated with some digging I did). it reproduces very nearly every time, but a sleep solves it, so I think it's a race between closing/freeing the handle and writing to it 10:45
(will backlog, leaving venue for a bit) 10:53
11:35 colomon joined 11:38 kjs_ joined 12:13 Ven joined 12:35 JimmyZ joined 12:38 btyler_yapc joined
dalek arVM: d78c018 | (Jimmy Zhuo)++ | src/core/threads.c:
remove a needless MVMROOT
 12:48
arVM: ff26781 | paultcochrane++ | src/core/nativecall_dyncall.c:
Add missing break statement to callback_handler switch cascade

It seems that a break statement is missing in the MVM_NATIVECALL_ARG_* cascade of case statements. This adds the missing break. The NQP tests pass.		 12:50
arVM: e6d1074 | (Jimmy Zhuo)++ | src/core/nativecall_dyncall.c:
Merge pull request #249 from paultcochrane/pr/add-missing-break-statement

Add missing break statement to callback_handler switch cascade
13:10 btyler_yapc joined 13:41 Ven_ joined 14:12 Ven_ joined
btyler_yapc I think this: github.com/MoarVM/MoarVM/pull/255 resolves the segfault I mentioned earlier. Unfortunately you can still make things explode by doing $sock.close and $sock.print("stuff"), but I'll poke at that next :) 14:15
timotimo btyler_yapc: oh, is your github user kanatohodets? 14:22
btyler_yapc yep, that's me 14:23
timotimo i totally didn't know that 14:24
14:25 lizmat joined 14:26 kjs_ joined 14:29 FROGGS joined 14:45 kjs_ joined 14:59 Ven_ joined
hoelzro proc async has some race conditiony stuff in it; I wouldn't be surprised if async socket did too 15:07
lizmat hoelzro: me neither :-) 15:08
hoelzro as long as I'm here...I've been working on updating nqp-js' deserializer to work with MoarVM serialization format 15, but the final solution seems to be eluding me. Is there a way to get --dump to tell me how many objects/stables/etc are in an SC, and where in the SC they are sleeping? 15:09
15:10 zakharyas joined 15:11 njmurphy joined
hoelzro btyler_: does $sock.close work instantly on the socket? or does it get scheduled in the async queue? 15:12
it should probably do the latter
timotimo if it's an async socket, then yeah, totally should 15:19
15:41 rarara joined
JimmyZ jnthn: it would be nice to take a quick review to PR 255 :) 15:46
jnthn I think that "if" becomes kinda redundant if we remove the NULLing, but we probably also remove a race by pushing things off to the event loop thread to deal with 15:52
Hm, actually there probably ain't a race. 15:53
But yeah, the if check is redundant
(if the NULL-ing goes away)
And it probably does have to go away.
JimmyZ so we can merge it and remove the if check 15:55
jnthn I think I'm good with that 15:57
dalek arVM: afbc27a | (Ben Tyler)++ | src/io/asyncsocket.c:
Fix write to null handle on async socket.

This NULL-ing in close_socket was premature, since MVM_free catches this same handle when the task is processed by the event loop in 38d153d | (Jimmy Zhuo)++ | src/io/asyncsocket.c: remove redundant if check		 16:03
16:04 dalek joined
16:09 btyler_yapc joined
btyler_yapc hi -- saw the backlog. the close already is scheduled on the event loop 16:10
thanks for taking a look! 16:11
it isn't obvious that it's an async close at first glance, because nqp::closefh eventually winds up in MVM_io_close, which wraps different kinds of closing for different things; async sockets implement that API with a uv scheduled close (at least, this is my understanding) 16:12
JimmyZ jnthn: btw: I think I found a bug which is in fixed allocation . FYI. 16:18
jnthn: issues/234, that's it 16:19
jnthn Possibly, but it's equally likely that the different memory layout achieved by turning on FSA_DEBUG just hides the issue 16:21
It should make the issue more ASAN-able though
JimmyZ yeah. 16:22
FAS_DEBUG looks like always malloc() 16:24
timotimo jnthn: can you help me figure out why our code-gen would produce a lexicalref-decl'd var for things like "my int $foo; while $foo < 10 { $foo++ }"?
jnthn Uh...well, the ++ operator will have one. 16:25
timotimo i can see why it'd want to use a lexicalref scoped mention of it later on, but why is that in the declaration?
oh, my example code doesn't actually ++, it just says the value
and i don't entirely understand why the lexicalref decl'd var actuallly works, as there's no lexical it can refer to :| 16:26
in "my int $foo" the code we generate is basically assign_i(my lexicalref int $foo, 0) 16:27
BBIAB 16:28
last time i looked at the code, it looked like it was supposed to never set lexicalref when it created the QAST::Var when $*IN_DECL was set to something specific 17:49
timotimo looks again
ah, yes, $*IN_DECL ne 'variable' 17:50
that surprised me quite a bit, as it was actually a variable declaration that was resulting in a lexicalref var 17:52
and even then it'd only set it if the lexical is marked ro
this may actually be the wrong piece of code i'm looking at, but there's not many other places that set lexicalref 18:05
18:13 pyrimidine joined, dalek joined 19:21 colomon joined
dalek arVM: fe40cbf | FROGGS++ | / (9 files):
re-apply patch to add C++/NativeCall support
 19:35
timotimo oh, huh, we just always set the scope to lexicalref if we have a non-object, huh? 20:12
that doesn't unify with how i understand lexicalref'd vars are code-gen'd 20:14
20:15 diakopte1 joined 21:03 Ven joined 21:08 ShimmerFairy joined 21:10 ashleydev joined 21:11 diakopter joined 21:16 lizmat joined, lizmat_ joined 21:55 Ven joined 23:02 japhb joined 23:07 japhb 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!