01:02 FROGGS_ joined 01:48 ilbot3 joined 01:59 FROGGS__ joined 06:59 domidumont joined 07:04 domidumont joined 07:53 domidumont joined
FROGGS__ o/ 09:07
nwc10 \__o 09:12
dogbert17 o/ anyone around with the power to merge an approved pull request 09:36
i.e. github.com/MoarVM/MoarVM/pull/429 09:37
nwc10 I don't have the power 09:44
dalek arVM: da6a530 | (Jan-Olof Hendig)++ | src/6model/reprs/NFA.c:
Fix memory leaks in nqp_nfa_run.

MVM_unicode_normalizer_init allocates a buffer which, after use, should be deallocated by a call to MVM_unicode_normalizer_cleanup. If this is not done a memory leak occurs. There were three places in the file where the call to MVM_unicode_normalizer_cleanup had been forgotten.
09:45
dogbert17 nwc10: perhaps someone who does will show sooner or later :)
arVM: 80aa6f7 | timo++ | src/6model/reprs/NFA.c:
Merge pull request #429 from dogbert17/master

Fix memory leaks in nqp_nfa_run - dogbert17++ 0c973ea | skids++ | src/math/bigintops.c: Workaround tommath issue #56 which affects random bigint numbers > 32 bits
   See rakudo RT#109586
dogbert17 timotimo++
timotimo o/
dogbert17 many thanks
timotimo thank you for your work & attention :) 09:47
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=109586
dalek arVM: d60390f | skids++ | src/math/bigintops.c:
Oops missed a spot... move one more bit over.
MoarVM: 3f1ef57 | FROGGS++ | src/math/bigintops.c:
MoarVM: Merge pull request #357 from skids/rand
MoarVM:
timotimo thank you, skids 10:54
i would have liked this to have gone in before the release, but it's not so terribly critical
people shouldn't expect pseudorandom numbers to have any qualities at all
if they need good-quality random numbers, they ought to ask their platform-supplied APIs 10:56
filtering for "random" in modules.perl6.org doesn't seem to give a good crypto-quality random number thing 10:58
there's a "Crypt::Random" that i first thought was pseudorandom 10:59
is /dev/urandom good enough for crypto? i didn't think it was, i thought you have to go for /dev/random instead?
nine There's no reason to use /dev/random 11:11
/dev/urandom uses a CSPRNG which by definition should be good enough for crypto. As long as it got seeded with enough entropy. Which unless your code runs during the boot it very probably has been. 11:13
jnthn suspects github.com/MoarVM/MoarVM/issues/430 is a case of an over-eager static analyzer, but further digging welcome. 11:25
FROGGS jnthn: so the statement itself is valid? MVMint16 body = offsetof(MVMP6opaque, body); 11:27
jnthn: I dont even get what it does 11:28
ohh, there is an explanation
jnthn :)
Yeah, see the link I included also
FROGGS I see 11:29
let's close it then :o)
jnthn I'm sure that isn't the only place that we use offsetof though?
Wonder why others don't trip up on it 11:30
Maybe the check for "is symbol declared on LHS mentioned on RHS" is a bit too simplistic or something though
11:31 TimToady joined
FROGGS most likely, yes 11:53
dogbert17 Anyone care to speculate as to what's happening here (valgrind output): gist.github.com/dogbert17/9c273abb...145a765985 12:04
FROGGS dogbert17: is that a 32bit system? 12:09
nine I think so
dogbert17 you'ld be right :) 12:10
nine: btw, thanks for fixing a bunch of these earlier this week 12:11
nine dogbert17: you're welcome :)
dogbert17 I have to admit that I have no idea how to fix this (and the one in 04-nativecal/08-callbacks.t) 12:12
nine Looks like we free an SC while still using it in another thread 12:14
FROGGS dogbert17: I wanted to look at the callbacks thing today
I dont know know whats going on either
dogbert17 FROGGS: cool, here's what I have: gist.github.com/dogbert17/f3482b99...728699fcec 12:15
nine: and this only happens on 32 bit?
nine dogbert17: gut says no. But with concurrency issues you rarely have the luxury of them showing up consistently. 12:19
btw. we have MVMuint64, MVMint64, MVMuint32 and MVMint32 all in use for indexing into an SC's objects array. That's surely less than optimal. 12:20
12:27 Ven joined
dogbert17 nine: I have to run the test severeal times in order for it to fail 12:32
s/severeal/several/
FROGGS dogbert17: valgrind is quiet for callbacks.t on x86_64 12:56
dogbert17 FROGGS: so it's a 32 bit problem then 12:57
FROGGS aye
will run it on a 32bit system in a minute
dogbert17 cool
13:03 Ven joined 13:06 Ven joined, domidumont joined
FROGGS dogbert17: I can reproduce the issue 13:16
dogbert17 FROGGS: fantastic, any theories? 13:17
13:20 Ven joined 13:26 Zoffix left
FROGGS dogbert17: no :o( 13:29
dogbert17 FROGGS: uh oh 13:38
14:05 dalek joined 14:30 Ven joined 14:45 Ven joined 14:50 zakharyas joined 14:59 geekosaur joined 15:12 geekosaur joined 16:39 zakharyas joined 16:52 zakharyas joined 18:12 Dunearhp joined 19:19 domidumont joined 19:54 zakharyas joined 21:24 geekosaur joined 22:37 lizmat joined 22:56 lizmat joined 23:01 lizmat_ joined