|
00:19
Morfent joined
00:40
TimToady joined
01:15
MasterDuke joined
03:01
ilbot3 joined
04:05
bart___ joined
|
|||
| 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 | |
|
06:37
brrt joined
06:54
domidumont joined
07:01
domidumont joined
|
|||
| 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 | ||
|
07:46
brrt joined
09:28
zakharyas joined
09:44
Ven` joined
10:37
brrt joined
11:27
Ven` joined
13:14
Ven` joined
13:34
AlexDaniel joined
14:20
Ven` joined
|
|||
| 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 | |||
|
14:45
Zoffix joined
|
|||
| 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 | |
|
14:48
Zoffix left
|
|||
| 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 | |
|
15:05
zakharyas joined
|
|||
| brrt | i k now | 15:06 | |
| so i'm not sure how the leak happens | 15:07 | ||
|
15:09
geospeck joined
16:08
brrt joined
|
|||
| 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 | ||
|
17:01
AlexDaniel joined
17:05
domidumont joined
|
|||
| 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 | |
|
18:39
geospeck joined
20:15
geospeck joined
20:30
geospeck joined
20:57
committable6 joined
20:58
releasable6 joined,
nativecallable6 joined,
squashable6 joined,
bloatable6 joined,
greppable6 joined,
evalable6 joined,
quotable6 joined,
unicodable6 joined,
bisectable6 joined,
benchable6 joined,
reportable6 joined,
coverable6 joined,
statisfiable6 joined
20:59
dogbert17 joined
|
|||
| dogbert17 | thought we'd gotten rid of the 'Must not GC when in the specializer/JIT' but I was wrong | 21:02 | |
|
22:26
ggoebel joined
23:05
brrt joined
23:07
synopsebot joined,
Geth joined
23:10
Geth joined
23:13
Geth joined
23:15
MasterDuke joined
|
|||