| IRC logs at
Set by AlexDaniel on 12 June 2018.
03:25 leont left 05:10 squashable6 left 05:13 squashable6 joined 05:24 squashable6 left 05:25 squashable6 joined 06:21 Altai-man joined 06:46 sivoais_ joined 06:47 sivoais left 06:51 frost-lab joined 07:22 sivoais_ left, sivoais joined 07:52 sivoais left 07:57 sena_kun joined, patrickb joined 07:59 Altai-man left 08:03 sivoais joined
nwc10 good *, #moarvm 08:20
Geth MoarVM/probes: 4 commits pushed by (Nicholas Clark)++
nwc10 fixes a thinko in a commit message.
and we get to see if some of the failed CI tests are flappy
10:16 leont joined
Geth MoarVM/probes: fcc625d6b1 | (Nicholas Clark)++ | 5 files
Add a probe for asin() and acos() returning NaN for out of range input.

Similar to commit 5e031c917587f8b3 for pow(), Solaris also seems to show non-POSIX behaviour for asin() and acos(), for the same compilers...
As with the others can *sort of* read the behaviour as conformat:
   For finite values of x not in the range [-1,1], a domain error shall
... (13 more lines)
11:56 Altai-man joined 11:59 sena_kun left 12:03 patrickb left 12:19 frost-lab left 12:29 squashable6 left 12:31 squashable6 joined 12:41 patrickb joined 13:26 domidumont joined 13:47 domidumont left 15:57 sena_kun joined 15:59 Altai-man left
nwc10 nine: 17:01
ASAN very excited by t/spec/S17-promise/nonblocking-await.t
heap-use-after-free in MVM_frame_find_dynamic_using_frame_walker
17:01 domidumont joined 18:20 zakharyas joined, zakharyas left
nine nwc10: oh, that's interesting! 18:31
18:31 zakharyas joined
nine is it nicely reproducible? 18:32
I think using MVM_fixed_size_free_at_safepoint would be more appropriate here: 18:33
nwc10 I've reproduced it on two machines. Which only differ in debian version 18:34
and all the "usual" debugging paranoia:
+#define MVM_ARRAY_CONC_DEBUG 1 18:35
+#define FSA_SIZE_DEBUG 1
+#define MVM_GC_DEBUG 1
+#define HASH_DEBUG_ITER 1
18:35 domidumont left
nine Sounds like you're simply slowing it down enough to provoke the race 18:37
can reproduce that way 18:50
nwc10 good, because I had no idea what to do next. and had (I think mistakenly) assumed that you'd done something recently that caused it to appear 18:51
nine I think the bug is pretty straight forward. The call frame that started the async code returns and when it does so it frees its frame extra. But the async code tries to look up a dynamic (probably $*SCHEDULER or $*PROMISE) and accesses the caller frame's extra even when it's already freed. 18:54
What the proper fix is is not so clear though. Seems to do fine with MVM_fixed_size_free_at_safepoint, but there's also a mechanism to keep the frame extra (which contains the dynlex cache) alive. 18:56
18:58 zakharyas left 19:56 Altai-man joined 19:59 sena_kun left 20:06 MasterDuke left 20:16 lucasb joined 20:23 MasterDuke joined 21:50 zakharyas joined
Geth MoarVM: 22f1038a95 | (Patrick Böker)++ | src/io/procops.c
Change `procspawnasync` to explicitly take the program name

As the value passed as program name and arg0 need to be different in some cases (e.g. a space in the program name on Windows) we need to retrieve both separately. Rakudo can then dictate what each value should be. Part of a fix for rakudo/rakudo#4117
linkable6 RAKUDO#4117 [open]: routine run bad works in windows 10
Geth MoarVM: 34f9d8c7aa | (Patrick Böker)++ (committed using GitHub Web editor) | src/io/procops.c
Merge pull request #1408 from patrickbkr/fix-win-proc-with-space

Change `procspawnasync` to explicitly take the program name
22:06 patrickb left 22:14 Altai-man left 22:23 patrickb joined 22:55 travis-ci joined
travis-ci MoarVM build errored. Patrick Böker 'Merge pull request #1408 from patrickbkr/fix-win-proc-with-space 22:55
22:55 travis-ci left 22:57 patrickb left 22:59 zakharyas left 23:01 patrickb joined