|
01:13
timotimo joined
01:16
zakharyas joined
01:31
ggoebel joined
01:48
ilbot3 joined
04:42
travis-ci joined
|
|||
| travis-ci | MoarVM build passed. Timo Paulssen 'dogbert17++ found this memleak in ord_basechar_at' | 04:42 | |
| travis-ci.org/MoarVM/MoarVM/builds/167200153 github.com/MoarVM/MoarVM/compare/e...6364c02a2d | |||
|
04:42
travis-ci left
05:35
domidumont joined
05:40
domidumont joined
05:50
dataf4l joined
|
|||
| dataf4l | hey guys | 05:50 | |
| how does one run moar files? | |||
|
06:04
FROGGS joined
06:05
dataf4l joined
|
|||
| nwc10 | dataf4l: simplest example is to look at how nqp does it. The nqp wrapper script is: | 06:06 | |
| #!/bin/sh | |||
| exec /home/nicholas/Sandpit/moar-san/bin/moar nqp.moarvm "$@" | |||
| so effectively | |||
| moar file-of-bytecode.moarvm command line arguments for file-of-bytecode | 06:07 | ||
|
06:18
domidumont joined
06:24
domidumont joined
|
|||
| brrt[work] | FROGGS: you can gdb attach to the PID | 06:33 | |
| but that's not really relevant now | 06:35 | ||
|
06:37
nebuchadnezzar joined
07:03
ilbot3 joined
08:20
domidumont joined
10:10
Util joined,
hoelzro joined,
zostay joined,
_longines joined,
nine joined,
pyrimidine joined,
mtj_ joined,
btyler joined,
nwc10 joined,
avar joined,
konobi joined,
cxreg joined,
Dunearhp joined,
lizmat joined,
jnthn joined,
mst joined,
japhb joined,
TimToady joined,
flaviusb joined,
timotimo joined,
zakharyas joined,
ggoebel joined,
dalek joined,
domidumont joined
10:28
_longines joined,
nine joined,
pyrimidine joined,
mtj_ joined,
btyler joined,
nwc10 joined,
avar joined,
konobi joined,
cxreg joined,
Dunearhp joined,
lizmat joined,
jnthn joined,
mst joined,
japhb joined,
TimToady joined,
flaviusb joined,
timotimo joined,
ggoebel joined,
dalek joined,
Util joined,
hoelzro joined,
zostay joined,
domidumont joined,
nebuchadnezzar joined,
sivoais joined,
geekosaur joined,
psch joined,
ilmari joined,
stmuk_ joined,
diakopter joined,
camelia joined,
[Coke] joined,
arnsholt joined,
moritz joined
10:30
ChanServ joined
10:31
camelia joined
10:35
sivoais joined
13:36
zakharyas joined
13:40
dalek joined
13:53
dalek joined
14:06
domidumont joined
14:38
domidumont1 joined
15:21
dataf4l joined
15:23
FROGGS joined
|
|||
| FROGGS | o/ | 15:24 | |
|
15:40
domidumont joined
15:53
dataf4l joined
|
|||
| FROGGS | domidumont: I posted another comment just now | 15:57 | |
| domidumont: and yes, run() works while shell() isnt | |||
| though we want shell() because it uses PATH | |||
| I'm going to take a closer look at the shell() implementation in moar after dinner | 15:58 | ||
|
16:11
dataf4l joined
|
|||
| domidumont | FROGGS: I still have hangs with run command (see githun for details) | 16:20 | |
| FROGGS | hmmmm, interesting | 16:36 | |
|
16:50
dataf4l joined
16:55
dataf4l joined
17:23
dataf4l joined
17:35
dogbert17 joined
17:40
domidumont1 joined
|
|||
| FROGGS | it's hanging here: github.com/MoarVM/MoarVM/blob/mast...ops.c#L240 | 17:54 | |
| timotimo | libuv isn't finishing up the process being run? | 17:56 | |
| this is without capturing, yes? so there shouldn't be a pipe that's blocking because the receiving end isn't reading from it, right? | 17:57 | ||
| FROGGS | aye, aye and aye | ||
| timotimo | is it hanging inside libuv's "give me the next event that happens please" part? | 17:59 | |
| FROGGS | in epoll_wait, so yes | ||
| timotimo | hm. i wonder how hard it is to introspect (from inside gdb) what kinds of things are installed there | 18:00 | |
| FROGGS | I believe there is a race condition... I added more debug printf's and now it calls spawn_on_exit (which didnt happen before) and it does not hang | 18:01 | |
| btw, we do not ignore the stdin/stdour/stderr of the child process but we let inherit it | 18:02 | ||
| timotimo | yeah, spawn_on_exit is what kicks the process out of the eventloop | 18:03 | |
| and that causes uv_run to exit because the process is the only thing inside that eventloop | |||
| spawn_on_exit is the exit_cb on that process | |||
| FROGGS | yes | 18:04 | |
| timotimo | yes | ||
| FROGGS | so what could we do? | ||
| timotimo | maybe we can golf it to a program that does nothing but spawn that process using our functions (golfed, too, probably) and see if we can make it b0rk on that platform without the rest of moarvm? | ||
| dogbert17 | timotimo: thanks for helping out with the memory leak yesterday | 18:05 | |
| timotimo | dogbert17: no problem, was easy as cake :) | ||
| FROGGS | uff | ||
| timotimo | if it did call spawn_on_exit but it still would hang, we could perhaps have something like "another thread is putting extra stuff into our event loop that prevents the eventloop from terminating" | 18:06 | |
| dogbert17 | I found a few more of the same type and have now posted my first PR to MoarVM | ||
| timotimo | but that's not happening, so ... | ||
| fantastic :) | |||
| FROGGS | we could try uv_run(tc->loop, UV_RUN_NOWAIT); ... | ||
| timotimo | what does that do? | 18:07 | |
| FROGGS | does not block if there is nothing todo IIRC | ||
| timotimo | does that mean it returns immediately from uv_run? | ||
| FROGGS | I *think* so... | 18:08 | |
| would be bad probably | |||
| let's try | |||
| timotimo | but we rely on uv_run to block so we can have blocking run | ||
| that's exactly how we implement blocking i/o on top of async i/o | |||
| FROGGS | - UV_RUN_NOWAIT: Poll for i/o once but don't block if there are no | 18:11 | |
| pending callbacks. Returns zero if done (no active handles | |||
| or requests left), or non-zero if more callbacks are expected (meaning | |||
| you should run the event loop again sometime in the future). | |||
| I'm trying this now: | 18:12 | ||
| if (uv_run(tc->loop, UV_RUN_NOWAIT)) | |||
| uv_run(tc->loop, UV_RUN_DEFAULT); | |||
| dunno if that solves the race condition or just adds another one | |||
| damn, that also hangs | 18:13 | ||
| and the uv_run(tc->loop, UV_RUN_NOWAIT) on its own just makes it return early so that the shell() is not done when the other one kicks in | 18:14 | ||
| timotimo | :\ | 18:15 | |
| jnthn | Odd. afaik it just stays in run so long as there's something keeping the loop "alive" (which is why we ref/unref stuff in various places) | 18:18 | |
| timotimo | yeah | ||
| we haven't bumped our libuv dependency in a long time, right? | 18:23 | ||
| FROGGS | timotimo: it happens with the newer libuv that is packaged in debian | 18:24 | |
| timotimo | good to know | 18:25 | |
| we might really want to bump our libuv, though | |||
| FROGGS | that's the diff and the lines that might are to blame: github.com/libuv/libuv/compare/546...050a95L501 | ||
| [Coke] | jnthn: any thoughts on moarvm #426 ? | 18:26 | |
| timotimo | could this be problematic if we inherit stdio pipes there? | ||
| i don't know what the "nocheckstdio" means | |||
| FROGGS | github.com/libuv/libuv/blob/master...ore.c#L496 | 18:27 | |
| timotimo | ah, it just means stdio pipes are okay to be closed with this | ||
| jnthn | [Coke]: Didn't get to look at it yet, sorry. Will try to do so soon. | 18:28 | |
| timotimo | [Coke]: anything to report for the angular 2 profiler yet? :) | ||
| don't worry if you haven't had time to work on it yet | |||
| [Coke] | jnthn: no worries. | 18:36 | |
| timotimo: nope. thanks for the reminder, though! | |||
| timotimo | OK :) | 18:37 | |
| FROGGS | I cant make sense out of it ó.ò | 19:13 | |
|
20:35
dataf4l joined
|
|||
| timotimo | are we perhaps looking at the wrong end of the whole thing? | 22:27 | |
| could it be we are triggering something causing the program being run to hang? | |||
| and so we are right to block forever? because the program we're executing is glitching out? | 22:28 | ||