05:49 tomboy64 joined
nwc10 jnthn: ASAN! Spesh! GC! paste.scsys.co.uk/558389 05:55
06:14 domidumont joined 06:19 domidumont joined 07:00 brrt joined
jnthn nwc10: Wonder if that is the one timotimo had a branch with a suggested patch for... 08:36
nwc10 I don't know. I tested the branch for a few iterations 08:37
but then went back to master
this stuff is rare, so one can't use testing to figure out if a patch is a fix
08:37 stmuk_ joined 08:41 stmuk joined
brrt \o jnthn, nwc10 08:41
samcv good * 08:57
09:15 ilmari[m] joined
timotimo nwc10: you didn't apply my patch to try if it fixes things? :< 10:21
oh 10:22
nwc10 timotimo: as I said, I can't tell you if it fixes things, because the crash only happens about once a month
timotimo well, my branch should prevent coming to the gc from fix_wval
nwc10 this one's going to take code review to fix, not testing :-) 10:23
timotimo i guess that's fair 10:26
samcv good night everyone 10:33
timotimo nite samcv 10:37
it might help to put a litle flag in somewhere "currently in spesh" for the TC, and when it hits a gc safepoint and that flag is set it could abort 10:48
jnthn timotimo: I think that's already there wehen GC_DEBUG is turned on. 11:46
timotimo ah, ok, nwc didn't have that enabled, it seems 11:49
i had expected every single flag to be enabled without going over the actual patch in the paste :) 11:50
a neat debugging trick: if you want to place a breakpoint to be effective only after your program has reached a certain point, just stick a break point in CStruct.c:497 (it's the bind_attribute reprfunc) and then stick "class A is repr("CStruct") { has int32 $.a }; A.new(:10a);" into your user program 11:51
jnthn: while it's a bad, bad hack, i could get the number of calls to mergesubstates and mergesubrule to go down drastically by using the grammar once at the end of YAMLish.pm6 11:55
from 3184 and 3127 calls for mergesubstates and mergesubrule respectively 11:56
to 664 and 658
should i investigate further at all in this direction? if i craft the yaml document well, i can surely get it down even further 11:58
oh, now it's gone completely 12:01
12:27 dogbert17_ joined
dogbert17_ added some gdb output to github.com/MoarVM/MoarVM/issues/572 12:28
12:50 domidumont joined 12:55 domidumont joined 12:57 domidumont joined 13:01 TimToady joined
Zoffix "Out of range: attempted to read 0 bytes from filehandle" surely that's the most in-range number of bytes to read :/ 13:04
nwc10 except that for a read of 0, would a return of 0 be success or end of file? 13:05
(not that it likely matters to the caller at that point)
Zoffix It returns a Buf 13:06
nwc10 ah
in which case, ignore me :-)
Zoffix Oh, I'm in the wrong channel :D
geekosaur POSIX says read of length 0 may do error checks, and otherwise returns 0 not meaning EOF 13:07
Zoffix Ah
MasterDuke a read of 0 is allowed? 13:09
*should be 13:10
because moar doesn't: github.com/MoarVM/MoarVM/blob/mast...#L179-L180 13:11
Zoffix: ^^^ 13:12
geekosaur that is precisely what started this... 13:16
I was responding to nwc10's observation, in any case; what perl 6 does is for someone else to decide 13:17
Zoffix I just popped `|| 1` to my read size calculation, so I'm good.
Hmmm.. 13:20
"Out of range: attempted to read 600000000 bytes from filehandle"
So there's some sort of max size too?
geekosaur github.com/MoarVM/MoarVM/commit/c9ab59c6ba 13:21
not any more; bump moarvm
Zoffix wtf 13:22
What a coincidence
jnthn++ presciently fixing MoarVM
MasterDuke Zoffix: the bump you did yesterday to make that test i added to roast pass includes jnthn's commit. had you not updated since then? 13:26
Zoffix No, I was using my system perl6 to run my bench...
...which is about... slurping... a file... in binary mode. Exactly what the MoarVM fixes :S 13:27
MasterDuke \o/ 13:28
timotimo spooky :) 13:31
dogbert17_ so jnthn++ is sneaking in MoarVM fixes when nobody is looking :) 13:49
geekosaur I was looking, that's how I recognized Zoffix's issue :) 13:50
(also Geth was looking :)
dogbert17_ nwc10: out of interest, which test caused the ASAN barfage you posted earlier?
geekosaur++, Geth++ 13:51
nwc10 dogbert17_: running the spectest with harness6 13:52
(or wahtever it's called)
dogbert17_ ah, so it's not obvious which individual test file was the culprit
dogbert17_ guess it could have been the harness6 script itself, there are still some bugs in there 13:53
nwc10 no, it's the harness itself that is the culprit
dogbert17_ cool, jnthn will have plenty to do then time permitting :) 13:54
14:48 domidumont joined
jnthn I actually ran into the large slurp bug yesterday when I tried to SCP a large file 14:50
Using SSH::LibSSH
Zoffix Ah :) 14:51
jnthn I also did a thinko in the library that made it dead slow
After fixing that we can SCP an 100MB file using the library just as fast as the scp command line program :)
Zoffix \o/
jnthn If only everything else in my $dayjob project was so fast :P 14:52
dogbert17_ Write your $dayjob stuff in Perl6 :)
jnthn I largely am :P 14:54
14:57 domidumont joined 15:21 brrt joined 15:58 brrt joined 16:16 geekosaur joined 17:07 domidumont joined 19:25 AlexDaniel joined
samcv so now i can slurp my hard drive? sudo perl6 -e 'slurp "/dev/sda"' 21:23
it's only binary mode that's affected right? 21:24
Zoffix You could slurp it before too. Only nqp::readfh() is affected 21:25
Or at least is is.. not sure what else uses those limits from MoarVM 21:26
And large perl6 slurps use several nqp::readfh calls
samcv ah 21:34
is that changing to going to be only one or no
Zoffix nope 21:36
Ah
I guess IO::Path.slurp was indeed affected. 21:37
It's IO::Handle.slurp that reads in chunks (and still does)
jnthn Yeah, it's IO::Path.slurp that I discovered this on 21:40

Powered by Cro and the Raku® Programming Language.

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

Thank you!