01:48 ilbot3 joined
MasterDuke samcv: if you take a look at the gists i linked here github.com/MoarVM/MoarVM/issues/571, there are a lot of `Use of uninitialised value of size 8` or `Conditional jump or move depends on uninitialised value(s)` in unicode stuff 02:26
i can't really tell what's going on 02:27
samcv MasterDuke, and this is reproducable? 02:52
or occasional thing 02:53
MasterDuke every time so far 02:57
well, not the SEGV, but all those errors in valgrind 02:59
samcv ok thanks. will assign myself to it. not sure what causes it but 03:38
MasterDuke i'm not sure if some crazy code inside libssl/libcrypto is just confusing valgrind 03:42
samcv me either yeah. kinda weird 03:44
06:15 domidumont joined 06:19 domidumont joined 10:35 domidumont joined 10:44 domidumont joined
jnthn MasterDuke: www.hardening-consulting.com/en/pos...grind.html 10:49
tl;dr the uninitialized warnings are 'cus openssl uses uninitialzed stack state as a source of entropy 10:50
MasterDuke jnthn: ah, i kind of wondered about that but didn't actually search around to confirm 11:26
and all the errors in moar's unicode functions are just because openssl first confused valgrind with it's craziness? 11:27
jnthn Yeah, almost certainly 11:29
Because we're proessing data that comes back from openssl
And valgrind can track propagation of uninitialized values and things derived from them
MasterDuke cool, makes sense 11:30
however, i did get a segv the very first time i ran this: perl6-m --profile=heap -I modules/http-useragent/lib/ -e 'use HTTP::UserAgent; my $ua = HTTP::UserAgent.new; my $response = $ua.get("perl6.org"); say $response.content.chars' 11:32
jnthn Hmm 11:33
Is it multi-threaded, 'cus the profiler handles that not too well...
MasterDuke is there an easy way to check? i obviously didn't do anything explicitly multi-threaded, but don't know what H::UA and its dependencies are doing under the hood 11:35
jnthn Well, if you catch the segv in gdb then you can just info threads 11:38
And see how many it reports :)
MasterDuke i'll try to catch it 11:43
jnthn: btw, this change ( github.com/sergot/openssl/pull/37 ) created a drastically different heaptrack profile of doing `perl6-m -I modules/http-useragent/lib/,modules/openssl/lib -e 'use HTTP::UserAgent; my $ua = HTTP::UserAgent.new; for ^10 { my $response = $ua.get("perl6.org"); say $response.content.chars }'` 11:45
before, heaptrack reported 10Gb total allocated, virtually off of it by `push`, in VMArray.c 11:47
*all of it
after, it was 268Mb total allocated
11:54 geekosaur joined
jnthn Why doesn't it just do buf8.allocate($n) ? 12:04
m: say buf8.allocate(16)
camelia Buf[uint8]:0x<00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>
lizmat jnthn: maybe the code predates the existences of Buf.allocate ? 12:15
*existence
jnthn That's very possible, yes :) 12:16
But I suspect it'd be quite the speedup :)
lizmat yeah, Buf.allocate is from Feb 2016 12:19
m: say buf8.allocate(16,(1,2,3)) 12:20
camelia Buf[uint8]:0x<01 02 03 01 02 03 01 02 03 01 02 03 01 02 03 01>
lizmat whee :-)
MasterDuke jnthn++, lizmat++, i'll submit a new PR changing to that 12:21
but is the memory use/leakage from the previous way (0 xx $n) expected? 12:22
lizmat what is the exact code? 12:23
I could double check that, that leakage doesn't feel right :-)
MasterDuke this was my previous PR github.com/sergot/openssl/pull/37
inspired by github.com/sergot/http-useragent/issues/169 12:24
jnthn Total allocated being higher doesn't convey a leak 12:26
Just means there was a lot more memory churn 12:27
And it isn't so surprising in that xx will return a Seq, and then we really have to pull values out of it
It's possible of course we could more optimally implement it :)
MasterDuke yeah, just one get request caused 1million+ calls to push 12:28
jnthn Wow o.O
MasterDuke yeah, i had to double-check i was reading the number right
lizmat MasterDuke jnthn : the problem is really in the Blob.new(@a) candidate 12:29
self!push-list("initializ",nqp::create(self),@values)
MasterDuke correcting to "initialize" will fix everything? :P 12:30
lizmat eh, it's used for any error messages and then postfixes "ing" I believe
and it's taking the generic Seq route, rather than the optimized List route :-( 12:32
MasterDuke m: my int @i[10]; dd buf8.new(@i) 12:34
camelia Buf[uint8].new(0,0,0,0,0,0,0,0,0,0)
lizmat yeah, that takes the most expensive route 12:35
MasterDuke ^^^ that also uses the slow candidate (Buf.pm:43)
lizmat yup
MasterDuke because it's shaped
lizmat please rakudobug this 12:36
and I'll have a look at it
MasterDuke which isn't what i expected (though i don't know native shaped arrays well)
lizmat that code predates shaped arrays
MasterDuke will do
RT #131086 12:42
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131086
lizmat thanks!
MasterDuke np, thanks for looking into it 12:43
13:15 domidumont joined
jnthn line_coverage.c 14:07
src\instrument\line_coverage.c(2) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory
Busted build on Windows :(
timotimo oh crap! sorry!
(why don't we have travis?)
jnthn We do, but Travis doesn't do Windows :P
timotimo er 14:08
i meant appveyor
jnthn Maybe we need...what's the thingy that does? :)
Maybe you could set it up as penance for breaking the build? ;)
timotimo hah
could try that. we do have a bunch of modules that already build their own rakudo to test themselves
what did i even use unistd for 14:09
aha "write"
then perhaps i want fputs?
jnthn mebbe
msdn.microsoft.com/en-us/library/1...2147217396 14:10
It's _write on Windows
And comes from io.h
timotimo not sure what i'd have wanted the length parameter and the write function for 14:11
Geth MoarVM: 826259d77b | (Timo Paulssen)++ | src/instrument/line_coverage.c
don't use unistd + write, use fputs instead.

unbusts our build on windows		 14:14
geekosaur if you did need the binary/packet one, try fwrite 14:34
timotimo since my data also already ends with a null byte, i guess fputs would be sufficient? 14:35
14:37 leego joined
Geth MoarVM: 5d73bf4b98 | (Timo Paulssen)++ | src/6model/reprs/P6int.c
cope with a native type with no nativesize, but signedness

by setting default_storage_spec.bits		 14:42
14:50 Geth joined 15:31 zakharyas joined 15:59 Ven joined
jnthn timotimo: Confirm that fixes the build; thanks! 16:02
c:\consulting\moarvm\src\instrument\line_coverage.c(53) : warning C4700: uninitialized local variable 'last_line_number' used
I get that warning, though, fwiw ;) 16:03
committable6 jnthn, ¦\consulting\moarvm\src\instrument\line_coverage.c(53): «Cannot find this revision (did you mean “7ddc5f7”?)»
jnthn haha
That's an...interesting suggestion :P
timotimo the what now? o_O 16:04
jnthn Something starting c: triggers commitable
timotimo good point, i should set last_line_number and last_filename into invalid values 16:05
ooooh
i was under the impression you pasted that as an output from msvc
jnthn Yes, the error I pasted was from MSVC
Then commitable reacted :)
timotimo yeah :D 16:06
AlexDaniel slaps committable6
c:HEAD say 42
committable6 AlexDaniel, ¦HEAD(932b59f): «42»
AlexDaniel this is not supposed to work…
b:say 42
bisectable6 AlexDaniel, On both starting points (old=2015.12 new=932b59f) the exit code is 0 and the output is identical as well
AlexDaniel, Output on both points: «42»
AlexDaniel or is it? Not even sure now 16:07
17:53 camelia joined 17:58 bartolin joined 18:06 MasterDuke joined 19:39 patrickz joined 20:05 Ven joined
samcv hello beautiful people 21:11
Zoffix \o 21:14
timotimo yo 21:17
lizmat samcv /o # feels honoured
samcv :-) 21:18
ok so. i am making coverage reports with travis. now where/how to upload them to some site for our viewing
initially just the overview reports
paging Zoffix
i guess for now i'll just have it print it out to travis' output 21:19
21:37 zakharyas joined
Geth MoarVM: 21fc7a226a | (Samantha McVey)++ | .gitignore
Add more coverage related files to .gitignore
 21:49
23:36 sivoais joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!