timotimo i just submitted a current moarvm build to coverity 01:30
i think the debugserver is new in this :D 01:31
we'll see the number of defects go up tenfold 01:33
May 29, 2018
Last Analyzed
Defect changes since previous build dated Aug 12, 2017
63 01:34
Newly detected
29
Eliminated
it finds an "integer overflowed argument" in twoway_memmem_uint32, interesting. 01:35
"overflow: add operation overflows on operands ms and 1UL", on line 143 of memmem32.c
i suppose that only happens with a string that's a few gigabytes or maybe even terabytes big?
geekosaur sounds like this is the kind of thing samcv wanted to add typedefs to fix, so everything uses consistent string lengths? 01:36
timotimo this is actually directly about straight-up memory buffers 01:37
i.e. no confusion as to what the individual graphemes are sized
geekosaur buffer lengths were randomly signed or unsigned 32 or 64 bit though
timotimo i see
geekosaur I also recall seeing that last time I poked at the string stuff 01:38
timotimo scan.coverity.com/projects/paultcochrane-moarvm - anyway, here's the link where you can find the "view defects" thing if you've got access 01:40
timotimo already fixed a few low-hanging fruits 01:51
timotimo Defect changes since previous build dated May 29, 2018 02:04
0
Newly detected
5
Eliminated
Geth MoarVM/master: 4 commits pushed by (Timo Paulssen)++ 02:18
brrt good * #moarvm 06:32
nullprogram.com/blog/2018/05/27/ <- this is of some interest to us (and to nine++, who wrote the JIT-nativecall thing)
nine .tell brrt indeed, it is interesting 07:10
yoleaux nine: I'll pass your message to brrt.
AlexDaniel squashable6: next 07:29
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 3 days and ≈2 hours (2018-06-02 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
timotimo moarvm defect density is approaching the "average defect density of OSS" :| 12:00
timotimo hack.p6c.org/~timo/ - fuzzing moarvm again 12:30
brrt that just means we're getting more features though :-P 12:32
yoleaux 07:10Z <nine> brrt: indeed, it is interesting
brrt timotimo: didn't you say there was a way to get repeatable thread scheduling somehow? 12:34
timotimo i don't recall details 12:34
i know that rr has a way to get the opposite :)
brrt either that or I figure out how to make the spesh worker be repeatable ....
timotimo or just turn it off; what are you looking to accomplish? 12:35
fwiw, fuzzing nqp code is not working well at all. perhaps i should have tried giving it a dictionary, because it's having ah ard time coming up with one by itself 12:36
i suppose an interpreter is pretty opaque to the fuzzer, and the jit is probably not helping matters
brrt i'm looking to debug a case where threads + the invokish removal thing causes an infinite loop 12:37
timotimo can i recommend rr again? 12:38
brrt you can
timotimo yeah, use rr for this :)
brrt let's, then 12:39
brrt hm, it is almost but not quite what i want... 12:49
brrt because it also keeps the environment variables the same 12:51
timotimo ah 12:55
without that it'll have a hard time replaying :)
brrt yeah, i guess that's true 13:04
dogbert17 brrt: have you looked at the latest coverity scan issue list, there are a couple if JIT related issues there 13:05
brrt i have 13:19
nine -win 10 13:54
nwc10 nine: you need to try harder to get into the accidental /win sweepstake 13:57
lizmat /win /win /win /win /win :-) 14:02
samcv good * 15:15
/win
timotimo good win 15:32
Geth MoarVM: db50291228 | (Samantha McVey)++ | 7 files
Speed of at_pos, bind_key and at_key by about 4% by speeding up dispatch

The compiler can optimize a little more if we add the functions in directly instead of using the pointer attached to the object.
These are used a lot in core compilation which is why I decided to optimize these specific ops.		 18:20
travis-ci MoarVM build errored. Samantha McVey 'Speed of at_pos, bind_key and at_key by about 4% by speeding up dispatch 18:37
travis-ci.org/MoarVM/MoarVM/builds/385331675 github.com/MoarVM/MoarVM/compare/9...502912281f
lizmat samcv: that looks very interesting :-) 20:26
brrt the invokish-remvoal-thread-bug is proving to be difficult to track down :-( 20:29
hmm. i can set degree =>1 and get a pretty nice and repeatable failure 20:37
problem is, there's just about 5 different invokish things in there
lizmat only 32 combinations 20:39
:-)
samcv lizmat: what does? the last commit? 20:44
lizmat yeah.. :-)
samcv :) 20:45
it's not a huge difference. but measurable
lizmat is tempted to bump Moar and nqp
samcv lizmat: go ahead :)
lizmat is testing 20:48
lizmat bumped 21:09
fwiw, looks like it's within noise for test-t, but Tux will tell 21:10
timotimo yeah, only tux will tell 21:11
who can say where the perf goes, where csv flows, only tux.
lizmat www.youtube.com/watch?v=4X0hJ3ac6yU # only s/time/tux/ will tell 21:19
timotimo let's perl together, whoa-oh 21:24
lizmat is too tired and goes to bed 21:42

Powered by Cro and the Raku® Programming Language.

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

Thank you!