github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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)		 10:38
nwc10 nine: paste.scsys.co.uk/594311 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
nine nwc10: oh, that's interesting! 18:31
nine is it nicely reproducible? 18:32
I think using MVM_fixed_size_free_at_safepoint would be more appropriate here: github.com/MoarVM/MoarVM/blob/mast...ame.c#L885 18:33
nwc10 I've reproduced it on two machines. Which only differ in debian version 18:34
but it is with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 MVM_SPESH_CHECK_DU=1
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
+#define MVM_SPESH_CHECK_DU 1
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
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		 21:50
linkable6 RAKUDO#4117 [open]: github.com/rakudo/rakudo/issues/4117 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
travis-ci MoarVM build errored. Patrick Böker 'Merge pull request #1408 from patrickbkr/fix-win-proc-with-space 22:55
travis-ci.org/MoarVM/MoarVM/builds/752191996 github.com/MoarVM/MoarVM/compare/7...f9d8c7aa2f

Powered by Cro and the Raku® Programming Language.

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

Thank you!