04:57 geekosaur joined 05:01 diakopter joined 05:23 domidumont joined 05:29 domidumont joined 05:56 domidumont joined 05:59 geekosaur joined 06:07 geekosaur joined 06:09 geekosaur joined 06:16 geekosaur joined 06:21 geekosaur joined 06:30 geekosaur joined 06:37 geekosaur joined 06:40 geekosaur joined 06:42 geekosaur joined
brrt timotimo: it is not strictly necessary, a refactor 06:56
i may be biased by my environment, but a refactor per se isn't always a good idea 06:57
07:33 zakharyas joined 07:52 lizmat joined 08:15 FROGGS joined
nwc10 good *, #moarvm 08:44
FROGGS morning nwc10 08:46
jnthn morning, #moarvm 08:58
Seems 'tis the season for colds :S
FROGGS :S 09:05
moritz it is :(
moritz works from home today in order not to spread it further
FROGGS will build a roof for a treehouse the next days and hopes it wont rain all day 09:06
jnthn isn't too bad...yet 09:07
There's actually a rename-related Windows precomp bug too :(
Now that the mkdir-related one is gone
FROGGS uff 09:08
jnthn Uh, to be clear: it was there before
FROGGS is that one new too?
ahh
jnthn Relatively new
It only seems to happen when you're editing modules
FROGGS but what's the bug?
jnthn It crashss with "Failed to rename file: operation not permitted" somewhere in the precomping process it seems 09:10
I'll try to get a small repro
Though I want to look in to github.com/MoarVM/MoarVM/issues/426 first 09:11
nwc10 jnthn: is there an strace equivalent for windows? In that, would you get that error on Win32 if it's attempting to rename a file which is open? 09:12
(A legal move on *nix filesystems)
jnthn nwc10: Renaming an open file had crossed my mind as a reason for this, yeah 09:15
There's various tools though not sure which would give more detail than "not permitted" 09:16
nwc10 was thinking that with strace on linux (or the equivalents) in the massively verbose log, one could find the "not permitted" error, and then work back to figure out which file it was, and when it was opend/closed 09:17
geekosaur strace equivs are few and far between and painful. but procmon and/or filemon would do it 09:32
jnthn github.com/MoarVM/MoarVM/issues/426 is proving a difficult golf... 09:34
Turns out that my $count = +$fixer.out.lines; can become my $count = 42;
Without losing the bug
But removing the run loses it
FROGGS :S 09:36
fairly hairy then
dalek arVM: 19d951d | jnthn++ | src/ (4 files):
Introduce MVM_SPESH_LIMIT.

For limiting the number of specializations produced. This can be used in conjunction with MVM_SPESH_LOG to bisect which particular frame's specialization leads to breakage.		 10:03
arVM: ad87cd9 | jnthn++ | src/spesh/candidate.c:
Correct thinko; alway spesh when no limit.
 10:29
jnthn Seems it's something to do with Spesh of 'elems' (cuid: 4215, file: gen/moar/m-CORE.setting:16795) 10:32
Turns out not; it got weirder 11:17
FROGGS :S 11:23
I guess that's the price for have a weirdtual machine... 11:24
jnthn Think I've figured it out at last 11:26
It's actaully about callframe 11:27
When we are doing the logging phase of a spesh'd frame, the annotations don't resolve right
timotimo dangerous op, that
oh, huh
that's a really weird one!
jnthn Well, it's because they refer to original bytecode offsets I guess 11:28
Anyway, the upshot of that is that in MVM_exception_backtrace:
if (fshi >= 0 && fshi < cur_frame->static_info->body.cu->body.num_strings)
value = MVM_repr_box_str(tc, MVM_hll_current(tc)->str_box_type,
We can't take that path
MVM_cu_string(tc, cur_frame->static_info->body.cu, fshi));
So we take this one:
else
value = MVM_repr_box_str(tc, MVM_hll_current(tc)->str_box_type,
cur_frame->static_info->body.cu->body.filename);
But since the file is in memory, not from disk, that is NULL
We thus box a NULL 11:29
timotimo and that null string blows up somewhere else?!
jnthn Which leads to the explosion in the code: "chars requires a concrete string, but got null"
What threw me off a bit is I was looking for a problem in the optimized code
While actually this is blowing up the moment we hit the logging code 11:30
timotimo i can imagine you would!
i just put in a cache for the three most used ContainerDescriptors and got a little reduction in both core setting size and a tiny bit more than that in rakudo startup memory usage
jnthn Nice 11:31
timotimo the three most used descriptors, btw, are %_ Mu (by a huge margin!), $_ Mu, and \c Any
jnthn Hm
But...I thought we already had them for $_ Mu
See magical_cds or so
Lunch time here; bbi30 or so
timotimo i shall investigate magical_cds
(they might have great music on them!)
jnthn :D 11:32
timotimo perhaps we have some $_ spelled out?
483 Container descriptor: $_ Mu, rw: 0, defaults to 'of' not dynamic 11:33
3838 Container descriptor: %_ Mu, rw: 0, defaults to 'of' not dynamic
this is across the whole core setting, so it's very possible those $_ are explicitly written "my $_ ..."
since there's an additional reduction in memory usage compared to just "the core setting file we mmap in got smaller", i'm hopeful this'll be a little saving for every additional method or sub that the user's code pulls in 11:37
jnthn back 12:01
Did you put in a general cache for identical CDs?
12:05 brrt joined
timotimo not yet, but i'm about to 12:07
to harness the power of The Long Tail
brrt notes to jnthn that he might be able to adapt the jit-bisect.pl tool in the even-moar-jit branch to bisect spesh
not that bisecting is hard, but when it is done for you, why not
jnthn Sounds nice :) 12:11
brrt although, the jit-bisect.pl tool also bisects the exact basic tree that starts going wrong 12:12
so it does a bunch of things that you strictly don't need
and, it uses prove etc... it was not designed for extensiblity
jnthn :) 12:13
Yeah, probably easier just to write another script
dalek arVM: 715e39a | jnthn++ | src/core/exceptions.c:
Make sure we never box a NULL filename.
 12:14
jnthn m: sub foo() { caller(1).file.ends-with('x') } for ^300 { foo() }; 12:15
camelia rakudo-moar eb6907: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Unexpected block in infix position (missing statement control word before the expression?)ā¤at <tmp>:1ā¤------> caller(1).file.ends-with('x') } for ^300ā { foo() };ā¤ expecting any of:ā¤ ā€¦Ā»
jnthn m: sub foo() { caller(1).file.ends-with('x') }; for ^300 { foo() };
camelia rakudo-moar eb6907: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Undeclared routine:ā¤ caller used at line 1ā¤ā¤Ā»
jnthn m: sub foo() { callframe(1).file.ends-with('x') }; for ^300 { foo() };
camelia rakudo-moar eb6907: OUTPUTĀ«chars requires a concrete string, but got nullā¤ in sub foo at <tmp> line 1ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
jnthn m: sub foo() { callframe(1).file.ends-with('x') }; for ^100 { foo() };
camelia ( no output )
jnthn m: sub foo() { callframe(1).file.ends-with('x') }; for ^300 { foo() };
camelia rakudo-moar eb6907: OUTPUTĀ«chars requires a concrete string, but got nullā¤ in sub foo at <tmp> line 1ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
jnthn There's a golf of what I just fixed :)
timotimo huh, having a "has %!foo" won't create a nqp::hash for me when a class is instantiated in nqp?
jnthn It easier to golf after you found the bug :P
timotimo well, apparently not
jnthn timotimo: not if the class has its own BUILD 12:16
timotimo aha, it does!
oh, i didn't know about Perl6CompilationContext 12:18
should the caches go there?
jnthn I...hmm 12:21
Where is magical_cds? :)
Probably same place as those
timotimo yeah, it's in that class 12:23
first measure, then move
domidumont FROGGS: remember the hanging moar on arm64. Here's an extract from /proc/xx/status while it's hung: SigBlk: 755e4cdab639e800 . If I interpret this correctly, SIGCHLD is blocked. And the mask value is weird. do you think that the right track ? 12:43
[Coke] jnthn: 426++ 12:45
jnthn for ^200 { next if $_ < 199; say callframe }
m: for ^200 { next if $_ < 199; say callframe }
camelia rakudo-moar eb6907: OUTPUTĀ«concatenate requires a concrete string, but got nullā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
timotimo same version as before still 12:46
jnthn Yeah, that's a separate MoarVM issue
[Coke] (hard to golf) I had a hard time getting it down to those 7 lines!
jnthn That it turns out is also fix
*fixed
timotimo oh, damn
but also: yeah!
jnthn So, two MoarVM issues down 12:53
[Coke]: Thanks for getting it down that far, at least :)
jnthn ponders what next :) 12:54
nwc10 lunch!
jnthn Already done that ;) 12:55
nwc10 jnthn++
timotimo jnthn: jdv has a bug that's been keeping them away from using perl6 more; it's an async related one
he's even been asking if there's "pay for bug" kind of stuff available 12:56
[Coke] RT #128833 - I was going to try to golf it, but probably won't be able to until this evening.
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128833
FROGGS domidumont: I dunno... I dont know much about signals... 12:57
timotimo yeah, it's using grammars from multiple threads and it's as if variables would suddenly change what's in them ...
jnthn timotimo: That's almost certainly a case of insufficient clsoure cloning
jnthn takes a look 12:58
timotimo i have no clue how to properly debug that kind of thing, tbh
jnthn Ah, is that the one that was being golfed somewhat above?
uh, not above, but over on #perl6-dev
timotimo do we have any diagnostics uncommentable that'll point out that kind of problem?
jnthn Not really
Though the cross-thread write logging is a good hint 12:59
timotimo # Failed test 'bound readonly sub param remains readonly (1)' 13:00
i wonder how my cache breaks that? o_O
i sure hope descriptors are never written to 13:02
jnthn Well, descriptors do get tweaked during compilation potentially
I *think*
Can't quite remember
Are you caching based on the rw flag too?
An ro $a and an rw $a need two different descriptors 13:03
timotimo only readonly will be cached at all
because the rw ones seem to have default values that aren't =:= the .of
my first instinct was to look at p6recont_ro, but that doesn't seem to touch the descriptor at all 13:04
it only looks to see if the descriptor says it's rw 13:05
"desc" only occurs two times in QASTCompilerMAST, and that's scsetdesc and scgetdesc :\ 13:07
timotimo AFK for a bit 13:11
13:14 mst joined 13:59 BinGOs joined
dogbert17 wonders what jnthn will tackle next 14:37
FROGGS .oO( might be tea )
dogbert17 shocking :-) when there's coffee 14:38
jnthn I did coffee this morning 14:39
Next will be get a test to cover the thing I just fixed into roast :)
brrt also does tea in the afternoon rather than coffee 14:40
dogbert17 has completed his moronic project, i.e. run every spectest (well 95%) through valgrind to see what if anything shows up (not incredibly much) 14:42
timotimo oh wow 14:44
that must have taken a *long* time
mst that sounds incredibly boring and also well worth doing
which is the sort of thing that often doesn't happen for open source projects
mst applauds dogbert17
dogbert17 it took quite a few hours 14:45
results are quite good I'd say, one spectest generating invalid reads and a few which leaks memory 14:46
jnthn dogbert17++ for taking the time to do this 14:47
dogbert17 I RT'd the one which generated the invalid reads, i.e. RT #129832 14:48
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129832
timotimo interestign. trying to deserialize from a serialized blob belonging to a compunit that got collected?? 14:51
i'm at least not aware of those blobs being shared 14:52
hm, but serialized blobs don't get mallocd and freed, tthey get mmapped, don't they?
dogbert17 makes coffee 14:53
timotimo ooooh
i know what this is
the vm is shutting down, but other threads haven't been stopped yet 14:54
dogbert17 every time I run valgrind on that test it ends with 'ERROR summary ....' followed by 'Killed' 14:55
jnthn Hm, I thought if we did full-cleanup then we got all threads sync'd 14:56
timotimo computer says "no" :) :)
jnthn I think next fix will, if I can find it, be for the darn annoying rename bug on Windows
Well, may not be a rename bug
bah, the tried STraceNT out of curiosity and it SEGVs before producing any data 15:12
dogbert17 what about geekosaur's suggestion, i.e. procmon 15:17
FROGGS jnthn: now you need to fix STraceNT first :P 15:19
jnthn dogbert17: That is much more intersting :) 15:31
(Was also reading docs for MoveFileExW :))
From that, it seems that the parent process of the one that gets in trouble when trying to rename has the target file open 15:42
japhb jnthn: If you're still looking for impactful tasks, the OO::Monitors 'no precompilation' thing would definitely reduce my daily annoyance because it would speed up my testing cycles considerably. :-) 15:56
timotimo what happens if you just remove "no precompilation"? :) 15:57
jnthn timotimo: "Can't serialize SCRef" 15:58
timotimo OK 16:00
jnthn I have a horrible feleing it'll be because I was clever enough to use macros 16:01
OO::Monitors might be the only module widely depended on that actually does that :P
I thought "ah, it'd be good to compile-time check condition variable names"
16:01 domidumont joined
jnthn Which is very clever but maybe not worth the inconvenience of not being able to pre-comp it 16:01
Dammit, I actually found a case of "file not closed when it should be" in CORE.setting, but it's not the one afflicting precomp on Windows 16:02
brrt interestingly, I believe I made that argument against precompilation just yesterday or so
as in, precompilation is fun, but macros are better
timotimo i was considering a pretty crazy project today: when serializing (or perhaps when deserializing?) record all positions in the bytestream before and after reading individual tiny pieces together with C-level backtraces, to split the whole serialized blob by what each byte is used for 16:03
jnthn brrt: I don't think they're at odds particularly... 16:09
brrt hmmm.... I think they can be 16:10
but it kind of depends on your ambitions
did you get to take a look at the spesh alloc extraction? 16:11
jnthn Not yet, sorry
brrt one thing I'm pondering is configurable block sizes
np :-)
jnthn Been bug hunting all day...
brrt it's a PR for a reason
jnthn Still am :P
16:34 Util joined
japhb
.oO( "Be vewwy vewwy quiet ... we're hunting bugs!" )
 17:05
timotimo is super hungry and super tired :\ 17:07
jnthn made lamb kebab thingies with feta in them, salad, and tatziki :) 18:25
Super full now
FROGGS (good food)++ 18:44
domidumont FROGGS: I've cornered the moar bug on arm64
FROGGS domidumont: wow, how so?
domidumont Turns out that the blocked SIGCHLD is the issue, introduced by a Debian patch :-( 18:45
on libuv
FROGGS uhh
bad patch! :P
domidumont The patch was added to fix a mips problem
I've added all the details on github
But I don't know what's wrong with Debian patch... 18:46
FROGGS yeah, I see the patch now... 18:47
domidumont Darn, this package is maintained by Debian javascript team, and I'm also part of this team :-p 18:49
FROGGS haha 18:50
it's also not obvious to me in what way this patch is faulty... 18:54
domidumont++ 18:55
geekosaur link? 18:56
FROGGS geekosaur: github.com/MoarVM/MoarVM/issues/42...-254901159
and: bugs.debian.org/cgi-bin/bugreport.cgi?bug=841354 18:57
timotimo mhhh tadziki 19:00
very tasty
geekosaur why is a uint64_t being replaced by a uint64_t* in the same call? 19:01
(sigmask with &sigset)
note that sigmask had the same type as sigset 19:02
geekosaur does a little poking, concludes that it should not be passing a pointer. what signals get blocked will depend on the bit pattern of the pointer... 19:04
so if you're in a position to do so, try with that patch but remove the & in the uv__epoll_pwait call (line 75 of the patch) 19:06
FROGGS geekosaur: but they've changed the signature of uv__epoll_pwait too 19:10
geekosaur hm.
did they change all uses too? didn;t see it in that patch... or is this really the only usage 19:11
FROGGS they must have, because they removed sigmask
geekosaur oh, yes, it is. but, now I wonder about the logic... because they were building sigset correctly but using the manually built sigmask. 19:13
manually as in manual bit twiddling
are the same bits really being twiddled on all platforms?
geekosaur goes back and looks at the bug again... those are really weird masks... 19:15
which is what made me think pointer
... OH 19:16
FROGGS one thinko might be that in line 49 'sigmask = 0;' is removed 19:17
geekosaur the sigset only ever gets sigemptyset-ed if SIGFPROC is added to it
FROGGS but 'sigemptyset(&sigset);' is not added there
geekosaur it's going to be random bits otherwise
er SIGPROF
FROGGS aye
19:18 dalek joined
FROGGS same thing we are talking about 19:18
domidumont: can you try moving the 'sigemptyset(&sigset);' in front of the condition? 19:21
I'm cloning the libuv package currently, but it'll take time
domidumont geekosaur, FROGGS: I'll have a look tomorrow 19:39
geekosaur submits that observation to debian's bug tracker 19:50
20:06 pyrimidi_ joined 20:08 pyrimidi_ joined
FROGGS geekosaur: I just sent a patch to the bug tracker... (tested it successfully on arm64) 22:06
geekosaur saw, yes
22:07 lizmat joined
FROGGS took a while to actually test it 22:12
arm64 on qemu is not quite fast
gnight 22:20

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!