00:00 lizmat joined 00:12 reportable6 joined 00:27 Kaiepi joined 01:09 bisectable6 joined 01:57 ilbot3 joined 02:10 yoleaux joined 03:58 greppable6 joined 04:04 ilmari_ joined 04:05 ilmari joined 04:44 Voldenet joined 04:50 Voldenet joined 04:57 ilmari[m] joined 05:24 wictory[m] joined 05:44 eater joined 05:45 AlexDaniel` joined 06:21 lizmat joined 06:35 domidumont joined 06:42 domidumont joined 06:44 robertle joined 07:16 AlexDaniel joined
nwc10 good *, #moarvm 08:22
08:27 AlexDaniel joined 09:34 zakharyas joined 09:37 lizmat joined
jnthn o/ 10:51
dogbert2_ good afternoon jnthn 10:57
it's quite silent/empty here so far today 11:01
as always I'm trying to lure someone to take a look at some suspicious gdb output 11:07
nwc10 I think folks only work mornings here :-)
jnthn lost most of his morning to visitng the dentist, alas 11:08
dogbert2_ where I live visiting the dentist => cavity in the wallet
robertle hi jnthn, I was wondering whether you could give me some tips about R#1711? note that this is different from earlier big-endian issues insofar that a) it is intermittent and not immediately reproducible, and b) that the error message always says "offset 0, instruction 0" (zeroes) 11:15
synopsebot R#1711 [open]: github.com/rakudo/rakudo/issues/1711 [severe] intermittent "Bytecode validation error at offset 0, instruction 0" on s390x/mips
robertle I am wondering whether there is anything I can do to shed some light on it. MVM_SPESH_DISABLE does not prevent it, 11:16
jnthn hah, that was going to be my first question
robertle I thought so ;)
jnthn Does valgrind work on such platforms and does it show any memory errors when this happens?
robertle I have not tried, but it is quite intermittent. I need to run the test suite in a loop for a long time before getting any failures. I guess valgrind will slow that down even more. but I can try... 11:17
I find the zero offset interesting, isn't it? 11:18
timotimo ISTR bytecode validation only runs when we load a piece of bytecode for the first time; since we do that lazily, maybe we can try turning off lazy deserialization and see if that makes the problem appear more often
yoleaux 09:39Z <lizmat> timotimo: updated
timotimo there might be a #define for that purpose 11:19
jnthn We run bytecode on first call to it
uh
*validate bytecode
It's orthogonal to lazy deserialization
timotimo OK, so there's also no eager bytecode validation
jnthn Yes, it's...interesting...that it's wrong at the start
timotimo: no, never has been
robertle: Are the tests that if fails ones involving threads? 11:20
robertle I did try some other SPESH environment variables to make it happen without any effect...
jnthn: I do believe so, lt me check.
not all, but there may be some noise in there. but the mayority looks like the last comment in the ticket, so definitely threads 11:21
11:23 lizmat joined
jnthn m: say 1039.base(16) 11:24
camelia 40F
jnthn m: say 40704.base(16)
camelia 9F00
jnthn m: say 0x9F 11:25
camelia 159
dogbert2_ clickbaits github.com/rakudo/rakudo/issues/1709 11:36
11:38 domidumont joined
nwc10 robertle: 11:51
#define MSG(val, msg) "Bytecode validation error at offset %" PRIu32 \
", instruction %" PRIu32 ":\n" msg, \
(MVMuint32)((val)->cur_op - (val)->bc_start), (val)->cur_instr
that's missing a cast on the second argument
robertle: the machine you have is 64 bit big endian? 11:52
er, technically third argument - the argument to the second formatting string
but that doesn't easily explain why it's two zeros. I would have expected 2 missing casts, to give 2 zeros
but what does the macro PRIu32 end up as on that machine? 11:53
ilmari nwc10: cur_instr is an MVMuint32, so doesn't need a cast, does it? 11:56
11:57 lizmat joined
ilmari and why doesn't that use PRiu8 instead of casting? 11:57
11:58 scovit joined
robertle some of them are 64bit yes, so would fixing this cast help debug this because we get better messages? 12:02
ilmari cur_op and bc_start are both MVMuint8, and cur_instr is MVMuint32 12:03
nwc10 ilmari: IIRC the rules of varargs in C is that everything integer is promoted to a long (and everything float is promoted to a double) 12:04
(in C++ char is not promoted)
hence if the format string says "32 bit" and the value is 32 bit, the promotion bites
but if you're little endian, you usually don't notice 12:05
ilmari ah
nwc10 note "IIRC"
evalable6 IIRC
nwc10 ooh
note "Lunch"
evalable6 Lunch
nwc10 robertle: I don't know for sure about "get better messages" but I think that fixing it (locally) and trying again might help
but if so, I'm a bit unsure as to why, as it ought only to fix the second 0 you see output 12:06
ilmari so changing the format string to PRIu64 might help
lizmat say so True
robertle ok, will do 12:07
lizmat hmmm.... 12:08
evalable6: say so True
evalable6 True
AlexDaniel lizmat: it looks a bit too much like normal text, so it doesn't eval it 12:09
say so True;
say so True; # foo
evalable6 True
AlexDaniel maybe it should
lizmat I sorta assumed it would try to EVAL and if that worked, show the result 12:12
12:27 lizmat joined 14:00 zakharyas joined
dogbert2_ hmm, SEGV, 0xb7a9e14b in check_lex (tc=0xa81bb68, f=0xaedc4418, idx=2) at src/core/interp.c:29. line 29 ? f->spesh_cand->lexical_types[idx] 14:08
jnthn hm, ain't check_lex the thing turned on by MVM_GC_DEBUG=2 ? 14:18
dogbert2_ interesting, I had indeed turned on MVM_GC_DEBUG=2 14:33
perhaps that was a mistake in this particular case 14:34
14:46 Kaiepi joined 15:15 zakharyas joined 16:14 domidumont joined 17:38 brrt joined
brrt \o 17:47
18:22 AlexDaniel joined
timotimo i wonder if we could do better with the unicode property values hashes that we generate in MVM_unicode_init; it looks like it allocates about 230 kilobytes 18:59
that's spread over 4.1k individual "blocks" (according to valgrind; not sure if each individual allocation call contributes one "block") 19:00
19:05 FROGGS joined 19:23 zakharyas joined
timotimo jnthn: is there a ticket associated with the profiler crash you had the other day with EVAL in a loop? 20:08
jnthn timotimo: I didn't create one, and I guess you'd know if there was an existing one that it falls under :) 20:12
timotimo um
timotimo shuffles through some heaps of paper on his desk
20:19 lizmat joined
timotimo somehow near the end of this heap snapshot, the indices get off the rails, or it forgets to write a marker in the right spot 20:34
the index does point at a position where the nature of data changes visibly in the hexdump
20:38 committable6 joined, evalable6 joined, quotable6 joined, nativecallable6 joined, notable6 joined, bloatable6 joined, coverable6 joined, unicodable6 joined, greppable6 joined, bisectable6 joined, reportable6 joined, benchable6 joined, shareable6 joined, statisfiable6 joined, squashable6 joined 20:39 undersightable6 joined, releasable6 joined 20:47 Kaiepi joined
timotimo looks like R#1713 is leaking frames from TPS, Promise, HyperPipeline, Lock, Supply, and Channel 20:55
synopsebot R#1713 [open]: github.com/rakudo/rakudo/issues/1713 [leak] Easily reproducible memory leak
timotimo oh, huh 20:58
here's a ThreadPoolScheduler::Queue (Object) that has a gazillion Block objects in it
86230 through 90704, though i didn't check to see if every number in between was in there 20:59
so, just lack of a backpressure method? 21:01
jnthn hyper pipelines do have a limit on number of items in flight 21:17
timotimo that's interesting
jnthn Basically, 2 * degree * batch size
Is the upper limit
Though for things actually being processed somewhere that factor of 2 goes away 21:18
The code in question is doing .batch(1), however 21:21
So that can't be to blame
Which raises the question, where the heck are all the things in the queue coming from?
timotimo does .List actually eagerly evaluate?
jnthn ah, hmmmm! :) 21:22
No
Does it stop leaking if writing .eager?
timotimo it's still running ...
8.5k Promise and Lock::ConditionVariable objects alive in the last snapshot
jnthn Hmm, that seems not right 21:24
timotimo memory use seems to be rising still 21:28
the rise isn't as clear-cut, it seems to be rather noisy 21:37
perhaps it depends on how the scheduler decides to spawn new workers or something
i had 151k for 2k times, 150k for 3.5k times, 128k for 4k times, 150k for 5k times 21:38
(that should be k²)
haha 21:52
perl6-m -e 'for ^7500 -> $go { (^100).race(batch=>1).map({ say "$go at $_" if $_ %% 20; $_ }).List }'
perl6-m -e 'for ^7500 -> $go { (^100).race(batch=>1).map({ say "$go at $_" if $_ %% 20; $_ }).eager.elems }'
guess how their output differs 21:53
jnthn Guessing the second works out rather better?
As in, displays $go in ascending order? 21:55
timotimo yup 21:58
the first one displays a looooong parade of 0s after "at" :)
so, my thought process goes like this:
we create about 10 thousand iterators that could at any point racemap through these lists
but nobody ever asks for the list to be iterated over
so they just hang out, chilling in preparation for real work, in the thread pool scheduler's queue 21:59
but work never comes
jnthn In theory, it was meant to work such that work had to be asked for, and everything would go away if the iterator also did 22:20
But yeah, sounds like that ain't happening
timotimo oh, do we have a DESTROY in play somewhere? 22:28
i'd expect something like that would have to be in HyperToIterator and RaceToIterator or something? 22:37
MasterDuke oh cool, looks like you've made some good findings 22:42
timotimo this is at least 25% user error :P 22:47
MasterDuke heh, i'm not even sure where the code example came from 22:56
dogbert17 it came from an RT :) 23:03
timotimo was the RT also about excessive memory usage? 23:04
dogbert17 no, it was when I and AlexDaniel tried to wrote a test for the original problem that the memory 'problem' was noticed 23:06
timotimo you know ... the debugserver could be used to build a grammar debugger that doesn't need the grammar to be recompiled
i.e. it could be used on the rakudo grammar, too
OK
i'd say that the situation that appears in the ticket itself shouldn't happen in real world code, as it doesn't actually do the work you're hoping it'd do
so it should be easy to spot that it's not doing what you want, and fixing it to actually consume the list will free memory appropriately 23:07
dogbert17 ah, RT #127974
synopsebot RT#127974 [open]: rt.perl.org/Ticket/Display.html?id=127974 [CONC] sprintf() not threadsafe/reentrant if the format tokens use explicit indices
timotimo wow, this is old 23:09
oh, but it was already fixed 23:10
so that's nice
dogbert17 sounds good, perhaps the issue should be closed ... unless AlexDaniel is of a different opinion
yeah, it was the when trying to write a test for the RT that the 'problem' cropped up
s/the when/when/ 23:11
MasterDuke: OT next gen Ryzen processors will be released on Thursday 23:13
slightly less OT, blogs.oracle.com/developers/announcing-graalvm 23:14
timotimo huh, wasn't graalvm announced already a year or two ago? 23:19
ok, so, actually: building a grammar debugger with the debug remote feature isn't possible. but building a Grammar::Tracer replacement should be 23:25
MasterDuke dogbert17: yeah, they're so very tempting. but ram prices are still kind of crazy 23:38
timotimo: is it possible to make it so the memory doesn't grow like that even if you aren't doing any work? 23:43
23:44 eater joined
timotimo i imagine so 23:48
trying a naive patch 23:51
it was not enough 23:54
damn, one of the workers in HyperPipeline actually holds on to the HyperToIterator object 23:56
until we have weak references, we can't get this done automatically, i don't think
how come, though, that it doesn't get sunk? 23:58
ok, being the last statement in the for loop prevents it from being sunk. do we want that, though? 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!