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
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
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
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
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
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
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!