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
|