brrt good * #moarvm 04:10
good night, for all intents and purposes
ASAN is complaining loudly of memory leaks in spesh
which is a pain because that was not what i wanted to research
patches coming up, obviously 04:11
Geth MoarVM/memory-leak-fixes: 85ca55f968 | (Bart Wiegmans)++ | 5 files
Fix memory leaks reported by ASAN

There were memory leaks in:
  - the string stream decoder separator specification buffer(s)
  - the static frame spesh body statistics buffer
  - the spesh plan type stats buffer
  - the spesh plan, when the static frame could not be added		 04:45
brrt there's another leak in nativecall build of the jit code object, it seems 05:20
but that's a bit more mysterious it seems 05:23
Geth MoarVM/memory-leak-fixes: 3a772a67c1 | (Bart Wiegmans)++ | src/strings/unicode_ops.c
Another leak in unicode_ops.c

Would decode string to ascii, which would allocate the result, which would then not be freed.		 05:24
brrt .tell nine we can apparently leak jitcode from MVM_nativecall_buidl 07:15
yoleaux brrt: I'll pass your message to nine.
brrt i'm not seeing how since i'd think that it be garbage-collected
Geth MoarVM: 509315503d | (Bart Wiegmans)++ | src/jit/linear_scan.c
[JIT] lets not overengineer linear-scan spill loop

The orignal pointer-pointer plus pointer was much simpler, so lets just make it explicit rather than muck about with && to force order and conditionality into assignment.		 07:16
Morfent sorry if this is the wrong place to ask, but would support for locales in moar be something that'd be worth contributing? 07:36
moritz Morfent: I think this is absolutely the right place to ask 07:39
my experience with locales in Perl 5 isn't great, so I'm a bit biased against them, but it's worth waiting for more opinions :-) 07:40
Morfent perfect, thanks
nine . 14:43
yoleaux 07:15Z <brrt> nine: we can apparently leak jitcode from MVM_nativecall_buidl
brrt ohai nine
nine hi brrt
brrt how are you doing 14:44
i'm not sure how exactly we leak jitocde, and to all extents it seems like we can be leaking expr trees
Zoffix Reminder: release is in 2 days and we still have 3 release blockers, if anyone can figure out how to fix them: github.com/rakudo/rakudo/issues?q=...2%9A%A0%22 14:45
lizmat S01-perl-5-integration/basic.t pretty much segfaults 50+% of the time for the "Passing a Perl 6 coderef to Perl 5" test 14:56
brrt blimey
lizmat oddly enough, this appears *less* if the system is under load
and I haven't been able to get it to crash with MVM_JIT_EXPR_DISABLE=1 14:57
nine brrt: all in all fine, though work right now requires pretty much all my energy. How're you? 15:00
brrt: do we leak jit code or jit graphs? 15:01
brrt jitcode 15:02
also jit trees, no jit graphs
i'm not sure how we leak them
nine brrt: that is only referenced by the NC body and freed in gc_cleanup 15:03
brrt i k now 15:06
so i'm not sure how the leak happens 15:07
brrt well, i do have a hypothesis though 16:14
this happens mostly in short-lived scripts
so i think it might happen if the process is shut down before spesh/JIT are done 16:15
timotimo uh oh 16:47
i can't send data on a tcp socket while i'm waiting for data on another 16:48
that seems rather ... bad?
nine brrt: MVM_SPESH_BLOCKING=1 should help confirm that hypothesis
brrt yeah, it stops the issue from happening
whcih doesn't *quite* prove there is nothing going on though 16:49
timotimo any opinions on whether we should split the io lock on tcp sockets into one for reading and one for writing? 18:22
lizmat full duplex seems to be the norm, so a split seems appropriate ? 18:25
timotimo i'm impressed it took that long for someone to stumble over this
lizmat well, I'm glad someone did stumble :-) 18:27
*and* reported it :-)
timotimo oh, huh 18:31
there are operations that are neither read nor write. like close 18:32
or seek or tell ...
ugh, this is kind of hairy
lizmat seek / tell on sockets ?
tcp sockets ? 18:33
timotimo or isatty, or fileno
libuv does offer read-write-locks 18:34
lizmat afk& 18:35
timotimo though that may not be the right thing at all. 18:38
dogbert17 thought we'd gotten rid of the 'Must not GC when in the specializer/JIT' but I was wrong 21:02

Powered by Cro and the Raku® Programming Language.

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

Thank you!