BenGoldberg m: INIT return; 00:04
camelia Attempt to return outside of any Routine
in block <unit> at <tmp> line 1
BenGoldberg m: sub { INIT return };
camelia (signal SEGV)
IOninja hehe 00:12
there's a ticket for it
rt.perl.org/Ticket/Display.html?id...et-history
BenGoldberg That's where I saw it.
IOninja Ah. OK :)
Don't make much sense, that code, but it at least shouldn't segv 00:13
BenGoldberg was reading the log for #moarvm.
geekosaur some ways p5's handling of that makes more sense to me (the INIT is a sub, so return would return from that) 00:39
...that stands a decent chance of being why the OP tripped over it
come to think of it, that could stand being mentioned in language/traps 00:43
old p5ers *will* be prone to doing that 00:44
IOninja didn't even know Perl 5 had INIT :o 00:58
$ perl -wlE 'END say "three"; INIT say "two"; BEGIN say "one";'
Illegal declaration of subroutine END at -e line 1.
now I remember why I dislike Perl 5 >_< 00:59
works with braces in. Cool. Only heard of BEGIN and END
01:12 pyrimidine joined
geekosaur BEGIN, UNITCHECK, CHECK, INIT, END 01:20
and yes, they are precisely subs; the "sub" keyword is optional, but the braces are required 01:21
IOninja :o 01:23
03:04 camelia joined 03:16 agentzh joined
BenGoldberg I've always thought of them as blocks, not subs, even if they can take an optional 'sub' keyword -- after all, it's not as if @_ has anything interesting in it (I don't think.) 04:20
04:29 pyrimidine joined 05:25 pyrimidine joined
geekosaur but they predate perl 5, and the notion of blocks :) 05:58
of course he just fell out of channel... 05:59
06:26 agentzh joined 06:27 pyrimidine joined
Geth MoarVM/even-moar-jit: abe040407e | (Bart Wiegmans)++ | 2 files
Start with compiling ARGLIST code

Will require topological sort to sort out correct ordering of value transfers in order to place them in the right registers, as well as cycle breaking. Also update plan, reordering items.		 06:43
06:47 brrt joined
brrt good * 06:47
in theory, the above comit is progress 06:48
08:18 agentzh joined 08:22 pyrimidine joined 08:28 pyrimidi_ joined 08:40 zakharyas joined 08:55 pyrimidine joined
jnthn morning o/ 09:43
samcv morning jnthn 09:45
09:47 stmuk joined
dogbert11 waves from $work 09:49
jnthn Got a fix for that INIT return thing 10:06
10:07 brrt joined
jnthn m: use Test; throws-like Q[sub { INIT return }], X::ControlFlow::Return 10:08
camelia (signal SEGV) 1..2
10:13 brrt joined
Geth MoarVM: a95639c380 | (Jonathan Worthington)++ | src/core/frame.c
Set effective_handlers in context-only frames.

Otherwise, if we somehow search in them for an exception handler, we will end up dereferencing a NULL pointer. This is cheaper than adding a NULL check into every exception throw.		 10:18
dogbert11 cool, that was quick
jnthn Yeah, dug around a bit to figure out the best place to fix it :)
dogbert11 what's next?
jnthn It spectests fine
Just fixing up the CHECK block error not giving a line number also 10:19
m: sub { CHECK return }
camelia ===SORRY!===
Attempt to return outside of any Routine
dogbert11 difficult? 10:20
jnthn No, we already have the infrastructure to make it good 10:22
Just had to apply it
Done now, just specteting :)
10:25 agentzh joined, pyrimidine joined 10:29 stmuk_ joined
jnthn There we go, another RT down. :) 10:33
What next... :)
dogbert11 do you want a siggestion? 10:35
perhaps rt.perl.org/Public/Bug/Display.html?id=126014 10:36
m: "x" xx 9999999999
camelia MoarVM panic: Memory allocation failed; could not allocate 79999999992 bytes
dogbert11 if the above looks interesting then some extra info can be found here: gist.github.com/dogbert17/e623faa8...1c5539dad9 10:39
10:41 brrt joined
jnthn m: my \lazy = "x" xx 9999999999 10:41
camelia MoarVM panic: Memory allocation failed; could not allocate 79999999992 bytes
jnthn m: my \lazy = "x" xx 9999999999; say lazy[0] 10:42
camelia MoarVM panic: Memory allocation failed; could not allocate 79999999992 bytes
jnthn Hmm
Geth MoarVM: 8c2a75f8af | (Samantha McVey)++ | src/strings/ops.c
Streamline switches, try to suppress Coverity warnings in

In MVM_string_compute_hash_code
MoarVM: 0feac4132a | (Jonathan Worthington)++ | src/strings/ops.c
Merge pull request #539 from samcv/hash

Streamline some switches and try to suppress Coverity warnings
jnthn m: say ("x" xx 99).WHAT 10:43
camelia (List)
jnthn m: say (rand xx 99).WHAT
camelia (List)
jnthn m: 42 xx (2 ** 62) 10:45
camelia (signal SEGV)
jnthn Aha
10:54 brrt joined
dogbert11 another SEGV 10:55
10:57 brrt1 joined 11:18 stmuk joined 11:22 stmuk_ joined 11:28 pyrimidine joined 11:30 stmuk joined
Geth MoarVM: b41c4e397a | (Jonathan Worthington)++ | src/6model/reprs/VMArray.c
Detect and throw on over-size array.

Otherwise, the multiplication with the element size can overflow; this leads to an allocation of zero (or a small number) of bytes, which we then SEGV on trying to zero because they are under-length.		 11:33
jnthn dogbert11: That should hopefully sort otu both the 32-bit and 64-bit cases of SEGV :)
11:33 agentzh joined 11:35 stmuk_ joined
jnthn Updated the ticket also 11:42
11:47 brrt joined 11:55 zakharyas joined 11:57 Geth joined
jnthn lunch & 11:58
dogbert11 nice :) have a nice lunch 12:01
m: 7 ~ "\x[308]" x 150_000 # is this the same SEGV? 12:22
camelia (signal SEGV)WARNINGS for <tmp>:
Useless use of "~" in expression "7 ~ \"\\x[308]\" x" in sink context (line 1)
jnthn back 12:29
dogbert11: No
dogbert11 its rt.perl.org/Public/Bug/Display.html?id=129227
12:29 pyrimidine joined
dogbert11 even though it SEGV's ASAN doesn't pick it up, have to run gdb to see what's going on 12:30
jnthn I suspect "too many combiners" or so
dogbert11 #0 0xb5fdb969 in MVM_fixed_size_alloc (tc=tc@entry=0xb5803c80, al=0xb4600fd0, bytes=bytes@entry=12) at src/core/fixedsizealloc.c:141 12:31
#1 0xb6202481 in twiddle_trie_node (tc=tc@entry=0xb5803c80, current=current@entry=0x0, cur_code=cur_code@entry=0xa7748890, codes_remaining=codes_remaining@entry=75213, synthetic=synthetic@entry=-8)
at src/strings/nfg.c:46
there are like thousands of twiddle_trie_node frames in gdb
jnthn Yeah, we should probably just stick an upper limit on combiners 12:32
There's really no practical use for more than even a pretty tiny number like 32
dogbert11 aha
if you crack this I have nothing more from the RT SEGV list, haven't found anything else that SEGV's and is reproducible 12:40
jnthn OK...are those that were tagged [SEGV] but no longer do untagged? 12:41
dogbert11 no, sadly I'm not able to make those changes
I was going to look at another one RT #130379, but I'm unable to find the branch the author is referring to (probably my git fu is not up to scratch) 12:43
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130379
[Coke] dogbert11: what's your RT login ID?
dogbert11 hm, am at $work but I think it was either dogbert17 or my email address 12:44
[Coke] dogbert11: you appear to already be a bugadmin. 12:46
dogbert11 but when I log in I only see my own cases 12:47
[Coke] on the home page? you can change what you see there. 12:48
Menu: logged in as <>; settings ; RT at a glance 12:49
also settings; quick search: be sure that "perl6" is checked. 12:50
dogbert11 will check again when I get home 12:53
if it works I could e.g. close RT #128705 12:54
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128705
13:00 agentzh joined
dogbert11 so if I'm to be trusted (NOT) we're beginning to run out of SEGV's 13:00
jnthn heh :) 13:01
Nice problem to have :P
brrt well, i'll be sure to bring you a few new ones 13:02
jnthn Oh no, not JIT ones /o\ :P 13:03
dogbert11 tbh, I have ignored the ones dealing with race and hyper ... 13:04
seem to remember that those two are broken 13:05
brrt matter of fact, with jit-bisect my (subjective) mean time between debug and resolution is much shorter 13:06
jnthn Yeah, race/hyper are the next big thing for me to work on 13:12
$ ./perl6-m -e 'my $x = 7 ~ "\x[308]" x 150_000' 13:23
Too many codepoints (150001) in grapheme in block <unit> at -e line 1
There we go :)
IOninja \o/ 13:24
jnthn I set the limit at 1024
Which still feels ridiculously high :)
But you'd pretty much have to be up to no good to hit it :)
IOninja Oh, never thought of just setting the limit when I looked at that bug :) 13:25
[Coke] should we make that a language restriction or is it a rakudo limit?
jnthn Good question.
I was kinda pondering that when thinking about testing it
I don't know that we want to dies-ok it 13:26
lives-ok { try 7 ~ "\x[308]" x 150_000 } looks a tad odd
But means all we're saying is "it either works or throws a real, catchable exception rather than bringing down the VM"
Which is a decent way to hedge :) 13:27
13:31 TimToady joined, pyrimidine joined
Geth MoarVM: 3d859008a6 | (Jonathan Worthington)++ | 2 files
Put in a limit for codepoints in a grapeheme.

Way higher than is going to occur in anything close to normal use, and prevents a stack overflow when forming the trie.		 13:35
dogbert11 jnthn++ a SEGV massacre 13:52
jnthn :-)
OK, time for language lesson :)
Back in an hour and a bit ;)
*:)
IOninja What sort of language are you lessoning? (giving or receiving?) 14:01
nwc10 I'm going to guess that it's one where the word for beer is "pivo" or something pretty close to that. 14:02
but (1) I don't know for sure and (2) it's a logged archived channel so I don't want to pre-empt what jnthn wants the world to know 14:03
moritz learning the vernacular sounds like a good idea, in general :-) 14:04
IOninja a Russian leson?
nwc10 "other slavic languages are available" (and acutally, I don't know) 14:05
dogbert11 moritz: did you find anything interesting with the newer cppcheck? 14:18
14:22 pyrimidine joined
moritz dogbert11: not really 14:22
dogbert11 timotimo has made a 'coverity scan' run, might be something in there 14:23
timotimo right. you'll have to ask for access on their site to get at the list of issues 14:26
14:27 pyrimidi_ joined
dogbert11 timotimo, I did that, what happens next 14:35
timotimo i check my mail :) 14:36
dogbert11 :) 14:37
timotimo oh i don't get it per mail it seems like?
i approved you as a "defect viewer (read-only)" 14:38
dogbert11 cool
timotimo i hae no idea why the "view defects" thing only shows one single defect at a time :\ 14:44
dogbert11 how many of these are real and not false positives? 14:53
defect 54936, is that legit? 14:57
timotimo: does jnthn have access to coverity? 15:03
timotimo could be legit 15:05
15:05 pyrimidine joined
jnthn back 15:15
IOninja: Czech, and it's me doing the learning :)
dogbert11: No, I don't have access to coverity, sadly 15:16
IOninja :)
timotimo oh, you can easily get it, though! 15:17
jnthn timotimo: Ooh, how?
timotimo go to scan.coverity.com, hit "sign in" at the top-right and use github to sign in/up 15:18
scan.coverity.com/projects/paultco...b=overview - somewhere around here it ought to give you a button to request access
jnthn aha 15:20
OK, it's now pending approval :)
timotimo you're now "maintainer/owner"
that also means you can upload builds
jnthn oh, you also could give me perms, nice :) 15:21
timotimo ptc made me "maintainer/owner", too 15:22
dogbert11 let the defect hunt begin 15:23
timotimo they have a check that you're not allowed to free a function pointer
seems like they don't get many jit writers :)
jnthn ;) 15:24
Wow, lots of nice stuff in there :)
The fixed size alloc resource leak ones seem to be a bit off at first glance 15:26
I suspect it doesn't understand CAS
timotimo yes, cas throws it off 15:27
oh, i did get mail for the requests, but they somehow escaped my attention 15:31
brrt well, we're not supposed to free() the function pointers; we're supposed to un-malloc them 15:32
if we do call a free on one of them, that's going to be very wrong
timotimo what :)
brrt ehm, un-mmap
timotimo oh?
brrt yea
yeah
you need a page to be able to set executable-flag on it 15:33
Geth MoarVM: 9a8ebea053 | (Jonathan Worthington)++ | src/profiler/instrument.c
Fix a missing NULL check.

Fixes CID 135426.
timotimo that's fair
brrt so you always get memory per page via mmap or the equivalent
timotimo right
jnthn Well, there's one down :)
dogbert11 maybe that's the only real problem in the list :) 15:37
jnthn Some others certainly warrant attention too :) 15:39
timotimo the coverity scan tool also allows you to mark things as false-positives, or "intended" 15:41
dogbert11 like e.g. deliberatly missing break statements 15:42
timotimo right
we might want to /* fallthrough */ there
maybe there's a common convention for that
dogbert11 I think samcv did something like that earlier today 15:43
timotimo yeah inside the unicode.c file i believe
when i fix coverity stuff i usually put the CID into the git commit message
geekosaur tried to. but I only know the old AT&T lint convention not the coverity one; I suggested looking for the manual
jnthn managed to get a variant of rt.perl.org/Ticket/Display.html?id=130796 to SEGV 16:01
dogbert11 what did that variant look like? 16:03
jnthn m: loop { my $c = 0; my \a = lazy gather { loop { take rand } }; my \b = lazy gather { loop { take rand } }; for ^10 -> $i { await start { a[$i] }, start { b[$i] } } }
camelia (signal SEGV)
jnthn Though it won't now I've done a darn debug/no-optimize build of course :P 16:04
dogbert11 :( 16:06
jnthn Will with just --debug
16:07 pyrimidine joined
dogbert11 jnthn: gist.github.com/dogbert17/9b61cf9b...0a52672c76 16:08
jnthn Yeah, it's somehow ending up leaking an iterationbuffer or something between threads 16:09
dogbert11 heh, now it crashed at a completely different place 16:12
#0 0xb573dbdd in MVM_hll_map /home/dogbert/repos/rakudo/nqp/MoarVM/src/core/hll.c:178 16:13
this gdb output might perhaps be of interest: gist.github.com/dogbert17/a856034c...5b52e1f204 16:15
jnthn Hm, looks like the gather/take golfs away too 16:22
my \a = lazy loop { 1 }; my \b = lazy loop { 1 }; for ^100000 -> $i { await start { a.AT-POS($i) }, start { b.AT-POS($i) } }
Providing that doesn't use gather/take under the hood
dogbert11 trying valgrind on the golf 16:30
jnthn Haven't found any good leads yet on what exactly is going on 16:33
dogbert11 and valgrind is dead slow ...zzz 16:34
jnthn Ah, but MVM_CROSS_THREAD_WRITE_LOG is far clearer on this golf :)
dogbert11 aha
jnthn Simplified by now to: my \a = lazy loop { 1 }; my \b = lazy loop { 1 }; for ^100000 -> $i { await start { a.AT-POS($i) }, start { b.AT-POS($i) } }
Thread 5 pushed to an object (IterationBuffer) allocated by thread 8 16:35
at <unknown>:1 (./CORE.setting.moarvm:push)
from SETTING::src/core/Iterator.pm:31 (./CORE.setting.moarvm:push-exactly)
dogbert11 if you fix it, does that make it 4 SEGV fixes in one day 16:38
jnthn Yeah, but...not having much look narrowing it down so far 16:43
Also, the cross-thread write log output was actually not a lead 16:50
timotimo :(
dogbert11 and the gdb gist didn't give any clues either? 17:00
jnthn Well, it explains where we crash
And at some level why
It doesn't explain, sadly, why we end up trying to push onto the same array twice 17:01
dogbert11 perhaps the answer hides in the coverity output 17:03
dogbert11 relocates 17:04
jnthn Still no luck. And getting a little tired, so will see if a break brings any fresh ideas. :) 17:11
17:31 ggoebel joined 17:43 agentzh joined 17:51 agentzh joined 18:06 pyrimidine joined 18:14 pyrimidine joined 19:08 japhb joined 19:57 agentzh joined 20:18 agentzh joined 20:21 ggoebel joined
dogbert17 jnthn: any brilliant ideas after having had dinner? 20:23
here's yet another gist, don't have high hopes that it will contain anything useful but you never know :) gist.github.com/dogbert17/2bd35157...244d740f0d 20:27
20:42 pyrimidine joined
jnthn dogbert17: Hm, that looks a bit like it's getting confused over our fixed size allocator. Would be interesting to put that in debug mode, which just mallocs (it's a #define at the top of src/core/fixedsizealloc.c) and seeing if the data races still show up 21:05
Didn't get any new ideas. Did get pretty tired though. :( 21:06
So it'll have to wait for another day 21:07
dogbert17 jnthn: well lots of SEGV's bit the dust today :) I'll try with fixedsizealloc 21:09
jnthn OK. If they're still there after that, they're much more interesting. :) 21:10
dogbert17 we'll see soon enough :) 21:11
jnthn Race errors are from helgrind? 21:12
dogbert17 yes 21:14
the number of helgrind problems went down quite a bit with the FSA_DEBUG flag on 21:18
jnthn Phew :)
dogbert17 the list is still quite long though but perhaps this tool also suffers from false positives 21:19
jnthn Well, some things are reasonable for it to catch for OK for us too
dogbert17 it's yelling about locks 21:20
the names AO_load_acquire and AO_store_release turns up several times 21:24
22:24 MasterDuke joined 22:37 agentzh joined
MasterDuke dogbert11: if you're looking for more segv, gist.github.com/MasterDuke17/a38df...45fa85bb4b has the valgrind output of RT #123434 23:15
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=123434
23:23 pyrimidine joined 23:48 agentzh joined
samcv good * 23:58
yoleaux2 20:25Z <IOninja> samcv: is it normal that "\c[rainbow flag]".chars == 2 ? It's listed in ZWJ sequence: unicode.org/emoji/charts/emoji-zwj-...ences.html

Powered by Cro and the Raku® Programming Language.

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

Thank you!