github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:59 lizmat left 01:54 stmuk_ joined 01:57 stmuk joined 01:59 stmuk_ left 05:12 stmuk_ joined 05:15 stmuk left 06:43 MasterDuke left, robertle joined 07:17 domidumont joined 07:18 domidumont left 07:19 domidumont joined 07:22 domidumont left 07:23 domidumont joined 07:42 zakharyas joined 08:04 zakharyas left 08:08 lizmat joined 08:09 zakharyas joined 08:44 brrt joined
brrt \o 09:03
09:04 zakharyas left
Geth MoarVM/jit-expr-refactor: 11 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/6...678c90f7cc		 09:04
09:06 zakharyas joined
jnthn morning o/ 09:06
yoleaux 03:29Z <MasterDuke> jnthn: at github.com/perl6/nqp/blob/master/d...operations there's a note `[As of 2014.04, these are very new and subject to revision and additions.]`. are the docs correct and complete enough now such that the caveat can be removed?
dogbert2 morning jnthn 09:12
jnthn committable6: 2018.06,HEAD sub p() { Proxy.new: FETCH => { 42 }, STORE => -> \cont, \val { say "assigned {val}" } }; p() = 42
committable6 jnthn, ¦2018.06: «assigned 42␤» ¦HEAD(4494a24): «Cannot modify an immutable Int (42)␤ in block <unit> at /tmp/FIrg0C1uLY line 1␤␤ «exit code = 1»»
samcv jnthn: i think i may go ahead with release since that person has not replied again about the hash overallocation 09:28
unless maybe there's some other way to contact them, maybe i can find their email on github 09:29
brrt maybe in the git commit log? (I don't knwo what this is about) 09:31
samcv;: i was wondering if you had any thoughts about in-situ strings for MoarVM 09:33
jnthn samcv: I've at least one more fix I need to look at.
There's a possible regression (or fix, I can't tell yet :)) in getlexcaller
09:46 brrt left
samcv jnthn: ah ok 09:46
10:03 zakharyas left
Geth MoarVM: ba906c4297 | (Jonathan Worthington)++ | src/spesh/frame_walker.c
Fix outer traversal regression in getlexcaller

The `cur_outer_frame` serves as a predicate, so we need to NULL it when we reach the end.		 10:11
lizmat jnthn: shall I bump Moar and NQP to test this ? 10:18
jnthn lizmat: Can do :)
lizmat will do 10:19
jnthn I just got pissing stresstest
*passing
o.O
dogbert2 lol
timotimo is it too tight to include the "get FD from socket" PRs we just got?
lizmat seems like it is an addition, rather than a fix, right ? 10:21
timotimo i'm wondering if it may have been too risky to push the "get source host and port from IO::Socket::Async" feature to master, too
yeah, it's a feature 10:24
masak "feature freezes" are both an incredible drag and a great risk-reducer. it's a tough tradeoff. 10:25
timotimo i hear you 10:26
masak I'm not even advising caution, or the lack thereof :P 10:27
timotimo yeah
masak just pointing out the tradeoff
timotimo it's also not my feature - at least the FD one
jnthn timotimo: I'd ask AlexDaniel++ to make a judgement on it; it may be we've already pushed our luck enough with this release, even if it is seemingly very safe 10:28
timotimo that makes sense 10:29
10:35 brrt joined 10:36 zakharyas joined
AlexDaniel well, it's hard for me to judge this one properly because I needed that feature a few times… so I'd much rather have it in the star release 10:36
but
timotimo: are there any tests?
timotimo there are all the IO::Socket::Async tests that make sure things that were already there don't break 10:37
i want to add tests, though
AlexDaniel yes but for that feature
samcv ok just saw the person had replied on the memory allocation. but not sure if this helps much? github.com/MoarVM/MoarVM/issues/910 10:38
though they seem to be implying that it may only be occuring with old glibc's 10:39
though i have 0 clue how that could have something to do with this
Current num buckets 33554432, tbl->num_items 1836, tbl->ineff_expands 0, tbl->noexpand 0
and this is not great. has 1836 items in the hash table yet has 33554432 buckets 10:40
which should be impossible
AlexDaniel haha
samcv also that seems to imply it's not just doing one huge allocation, but it is expanding over time? or something 10:41
since i had it MVM_oops with the patch if it tried to allocate over 1gb
log2 of 33554432 is 25 fyi 10:42
dogbert2 m: CONTROL { }; warn ""
camelia Warning: something's wrong
MoarVM panic: Trying to unwind over wrong handler
dogbert2 that's an oldie btw
timotimo hm, there's also udp sockets that you may also want to use port 0 on; that'll have to go in the next release in any case 10:45
AlexDaniel jnthn: oh yey, two blockers out. I'm rerunning toaster now 10:46
10:52 Ven`` joined, Ven`` left 11:03 Ven`` joined, zakharyas left 11:05 zakharyas joined 11:41 brrt left 11:48 zakharyas left 12:09 Ven`` left 12:10 Ven`` joined 12:30 Ven`` left 12:36 Ven`` joined 12:38 lizmat left 12:47 dogbert2 joined 12:52 Ven`` left 13:04 Ven`` joined
dogbert2 AlexDaniel: how long does a Toaster run take? 13:17
13:22 zakharyas joined 13:23 Ven`` left
dogbert2 if I run stresstest (on 32-bit) with a very small nursery and MVM_GC_DEBUG=2 I sometimes get a failure in t/spec/S32-io/io-path-extension.t 13:26
it point to this line github.com/MoarVM/MoarVM/blob/mast...ext.c#L151 could it be a missing MVMRoot ? 13:28
jnthn I don't immediately spot one 13:30
13:30 stmuk joined
dogbert2 jnthn: perhaps it's something else 13:31
#1 0xb7b110a4 in bind_key (tc=0x804c628, st=0x80b95b0, root=0x805c578, data=0x805c588, key=0x8cbe3b8, value=..., kind=8) at src/6model/reprs/MVMContext.c:151
#2 0xb7a674ae in MVM_interp_run (tc=0x804c628, initial_invoke=0xb7be0303 <toplevel_initial_invoke>, invoke_data=0x80e7178) at src/core/interp.c:2417
13:31 stmuk_ left 13:34 Ven`` joined
AlexDaniel dogbert2: this one was 141m8.915s for me 13:36
samcv is trying to compile glibc 2.12.1 and it's not very easy, needed a ton of patches to even get it to compile 13:37
AlexDaniel dogbert2: eh… results are up toast.6lang.org/ but 13:39
dogbert2: I think I forgot to bump
hmmmmmm 13:41
dogbert2 oops 13:42
AlexDaniel no, the bumps are actually there
ah, toaster was executed before the bump
ok, I see
AlexDaniel reruns
timotimo jnthn: you were mentioning the other day about paramnamesused being used with a null callsite? 13:43
gist.github.com/timo/93065f66404d1...23a15288fb - here in the atomic load prefix operator being used in Lock::Async is asploding 13:45
interestingly, there isn't a spesh candidate on cur_frame 13:46
13:48 lizmat joined
jnthn Yes, I never got to the bottom of that, but it's not a spesh bug, I don't think, 'cus I got it to explode with MVM_SPESH_DISABLE=1 13:48
timotimo yeah, the first spesh_cand in the stack is two outers out 13:49
with spesh_disable it is less interested in asploding 13:53
the program ran to completion :| 13:56
13:59 Ven`` left
timotimo moar: src/gc/collect.c:218: process_worklist: Assertion `*item_ptr != item->sc_forward_u.forwarder' failed. 14:07
so maybe it's actually general memory corruption that's breaking this, just somehow hitting the callsite portion of a frame
AlexDaniel anyone looking at github.com/rakudo/rakudo/issues/2070 ? 14:24
jnthn AlexDaniel: I think brrt++ did a bit this weekend, but without a solution 14:33
dogbert2 #0 0xb5bdf288 in MVM_interp_run (tc=tc@entry=0xb5403d00, initial_invoke=initial_invoke@entry=0xb60287d0 <toplevel_initial_invoke>, invoke_data=0x0) at src/core/interp.c:5814 14:46
^^ tobs SEGV from #perl6 14:47
15:04 zakharyas left
AlexDaniel fwiw that's GH#2120 15:08
synopsebot GH#2120 [open]: github.com/rakudo/rakudo/issues/2120 [regression][⚠ blocker ⚠] Segfault while indexing with infinite Seq
AlexDaniel and it's bisected, if that helps
well not down to moar commit, but to a bump at least
15:22 hoelzro joined
samcv well i can fully reproduce that allocation of a huge number of bytes on CentOS 6 15:36
15:48 robertle left, zakharyas joined 16:00 lizmat left 16:02 domidumont left 16:03 lizmat joined, zakharyas left
samcv this is pretty weird 16:06
asan doesn't work on this old of a gcc. so i'm going to try to use valgrind and figure out what's happening 16:07
16:08 bisectable6 joined
AlexDaniel dogbert2: well, alright, now it's there: toast.6lang.org/ 16:10
I was expecting a greener result…
timotimo we're not running a greenery here
AlexDaniel time for another ticket I guess 16:12
samcv gist.github.com/d4ead78b0a3cdf2c9f...ffbb7004c5 from valgrind 16:13
though this may be my fault.. since it's from a printf i added 16:14
lizmat AlexDaniel: is there a way to limit toast.6lang.org to a specific author ?
so e.g. I could easily see if any of my modules got burnt ?
AlexDaniel lizmat: unfortunately not, but with just 13 modules that turned red it's hardly a problem? 16:15
lizmat also: slightly worrying perhaps are the Cro:: fails ?
16:15 lizmat left
samcv yeah ignore that gist i posted 16:15
AlexDaniel if it failed on 2018.06 also it means that Cro is unhappy with the setup, or something like that 16:16
so yeah, toaster isn't exactly a precision tool :)
16:16 lizmat joined
AlexDaniel lizmat: colabti.org/irclogger/irclogger_log...07-23#l166 16:17
jnthn It's due to IO::Socket::Async not getting along libssl1.1
AlexDaniel lizmat: basically, some modules are just always red in toaster and we don't get any useful info out of them, yes 16:18
and that's LTA, yes, and I hope jnthn++ runs at least some tests with latest rakudo :) 16:19
16:19 nativecallable6 joined, benchable6 joined, squashable6 joined
jnthn I've used the Cro::HTTP test suite quite often as a "does this work for something interesting besides stresstest" check :) 16:20
(And yes, it's passing at present) 16:21
samcv jnthn: so it works perfectly in valgrind. so i'm thinking it may be some memory issue 16:23
or some race condition or something...
jnthn samcv: Hm, but are there any threads?
samcv no clue
jnthn Well there's be the specializer one I guess 16:24
But yeah, it's really odd
samcv jnthn: i can fix it by adding another conditional before expand_buckets. like if there's more items than buckets don't expand but that doesn't fix the actual issue 16:25
though it does cover it up effectively
jnthn Maybe add it with a comment that it's for a dodgy libc version? :) 16:26
I figure with time that libc version will fade from existence :)
jnthn -> home & 16:28
samcv though it is possible that things are just ending up in the same bucket, or that somehow the code that is supposed to stop things from expanding too many times stops working... but i will have to investigate a bit more 16:30
before i give up
but more weird because most of it is just pure c code and not stuff i'd think would be the purview of the library? 16:31
aha. ok. it fails the siphash tests. 16:32
lucikly i included those tests in our repo. so it seems glibc doesn't play nice with the siphash code
that would do it 16:33
16:34 dogbert17 joined 16:35 greppable6 joined 16:36 diakopter joined
AlexDaniel jnthn: I'm starting to doubt myself, can you take a look maybe? This PR: github.com/tadzik/Getopt-Type/pull/3 16:42
jnthn: basically there's a class with `method ACCEPTS($opts is rw) {…}`, and then it does `sub foo(*%opts where THAT-OBJECT) {}` 16:43
my understanding is that it doesn't need to be `is rw`, and even shouldn't be 16:44
The error is: # Parameter '$opts' expected a writable container, but got Hash value
samcv jnthn: so if i unset MVM_CAN_UNALIGNED_INT64 then things work properly 16:50
well after altering one place in the code 16:51
AlexDaniel jnthn: and I'm questioning it because it's pretty much the only module affected right now, everything else was covered by the Proxy compat thingie 16:55
tadzik huh, I missed that PR 17:10
AlexDaniel: are you actually using my stuff? Sick :) 17:11
or is there just some ecosystem test errors
17:20 yoleaux joined 17:38 statisfiable6 joined 18:10 stmuk_ joined 18:12 stmuk left
AlexDaniel tadzik: yeah, it was detected by toaster 18:28
tadzik: merging it will unbreak another module, btw 18:29
tadzik: and it's also yours :) github.com/tadzik/App-redpanda
18:41 Ven`` joined
timotimo jnthn: seems like zoffix figured out the segfault with the null callsite came from the whatever currier's migrator 18:51
19:00 Ven`` left
tadzik ah, redpanda, that brings back memories:P 19:17
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/07/23/...cate-guts/ 20:01
20:12 Ven`` joined 20:31 lizmat left 20:33 lizmat joined 20:34 MasterDuke joined 20:38 Ven` joined 20:40 Ven`` left 20:50 Ven` left 20:53 MasterDuke left
samcv i'm making progress fixing that issue with hash overallocation 20:53
20:53 MasterDuke joined
jnthn evening o/ 20:58
samcv evening o/
jnthn: so essentially this old glibc version has a bug with certain types of unaligned reads it seems 20:59
jnthn samcv: ah, "interesting" :S
samcv jnthn: though i'm unsure at how it causes it to totally break everything 21:00
since the only issues were with the siphash functions that "finish" off the hash 21:01
so it should only cause the last grapheme to cause an issue. though who knows what glibc's bug is
and it has no issue with 64 bit unaligned reads, but it seems to only have a bug with 32 bit unaligned reads 21:02
to fix i think i'm just going to turn them into 8bit reads instead, and modern comilers should optimize it into unaligned accesses.
and given these functions: siphash_finish (works with 8 bit orientation of bytes) and siphashfinish_32bits 21:03
and are only called once per string, it is not too hot a path so as to worry as much about compilers that may not optimize them into a single operation 21:04
jnthn Weird bug though 21:05
samcv++ for hunting it down
samcv yeah. the siphash tests i wrote saved the day though
jnthn Indeed :)
21:06 Kaiepi left
samcv otherwise it would have taken me way longer to figure this out 21:06
jnthn AlexDaniel: Hm, I thought I had an idea what the ACCEPTS/is rw change might have originated from, but now I look a bit more at it, the change I suspected doesn't fit the symptoms. 21:23
AlexDaniel: Though if anything it feels like a bug fix. 21:24
In that I'm not sure an rw thing should make it into the constraint
Geth MoarVM: f4662285db | (Samantha McVey)++ | 2 files
Don't use 32-bit unaligned reads in SipHash implementation

This fixes a bug on CentOS 6 and possibly is a bug in glibc 2.12.1 or the toolchain which has issues with unaligned 32-bit reads.
Instead of trying to do a 32-bit unaligned read, only do 8-bit reads. This should optimize to a single operation in the compiler, and even if it does not, we only called siphashfinish or siphashfinish_32bits once for every string we hash.
Fixes issue #910		 21:44
timotimo i don't really understand why glibc would be responsible for something as low-level as "reading memory" 21:54
samcv timotimo: i don't either 21:56
the reporter said that if they compiled differently which uses a newer glibc it didn't have the issue
timotimo right
21:57 Ven`` joined
timotimo i'm hoping this'll be something i can learn, but i feel super drained in the brain right now, for apparent reason 21:57
22:00 Ven`` left
AlexDaniel timotimo: I'm out of the loop, what's the reason? 22:07
22:07 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Don't use 32-bit unaligned reads in SipHash implementation 22:07
travis-ci.org/MoarVM/MoarVM/builds/407354673 github.com/MoarVM/MoarVM/compare/b...662285db2d
22:07 travis-ci left
timotimo AlexDaniel: i have no idea! 22:08
samcv looks like travis is a flopper 22:09
err whatever it is called. i am tired
AlexDaniel clicks “restart job”
timotimo we need a bot that clicks "restart job" on every failed job a few times or maybe forever until it succeeds
AlexDaniel yay, green 22:15
22:23 MasterDuke left 22:32 MasterDuke joined
samcv timotimo: :) 22:48
lol @forever 22:49
let's do that and see how long it takes until github messages us
AlexDaniel not github, but travis 22:58
whateverable is already throttled, but I think there's some issue on my side 22:59
like not setting a key or something like that
23:03 Kaiepi joined 23:21 scovit_ joined
scovit_ samcv, I am playing a bit with your code and godbolt.org, to me it seems like it is a gcc 4.4.7 bug and it emits code that basically calls siphashfinish_last_part(sh, t) with argument t = 0 23:22
samcv scovit_: hmm are you sure 23:26
scovit_: well it's fixed with my changes though+ 23:27
?
scovit_ it is fixed, yes, but I have a question: does your code just cast an int to a long long int ? 23:28
it might be wrong on bigendian
samcv it's not, at least the last time i checked it
scovit_ the new version I mean 23:29
samcv ah
hm that could be right. i will have to test it later
err actually no it should be fine 23:30
it's essentially doing a memcpy
scovit_ I really do not understand why you do not just set t equal to src
samcv so i'm pretty certain there's no issue, though i will check tomorrow
scovit_: that doesn't result in the same thing 23:31
scovit_ samcv setting t to src zeroes the most significant bits (the last 4 bytes) and set the first 4 to the src 23:32
on little-endian
timotimo do we already have a post-release branch?
AlexDaniel timotimo: feel free to start one 23:33
samcv scovit_: on big endian that's not the same thing
timotimo AlexDaniel: what do i call it?
scovit_ exactly, that is the only thing I am not sure about
AlexDaniel timotimo: post-release-2018.07 23:34
Geth MoarVM/post-release-2018.07: 33d6c9cebf | (Timo Paulssen)++ | src/spesh/optimize.c
Make sure output of spesh resolve gets optimized, too

Until now we'd have resumed optimization after the last instruction a speshresolve has put in. This misses the opportunity to improve getattr faux-guards into direct pointer access versions.
Fix this by remembering the previous instruction before speshresolve is optimized and continuing with that instruction. The next thing in the loop is to go to ins->next, so we use prev->prev.		 23:36
timotimo it'd be kind of cool to have this in the release. i think it's pretty safe. but it is really late in the release cycle

Powered by Cro and the Raku® Programming Language.

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

Thank you!