[#70252] Re: [ruby-cvs:58640] nobu:r51492 (trunk): node.c: NODE_ALLOCA for ALLOCV — Eric Wong <normalperson@...>
Besides possible backwards compatibility, can we drop volatile
3 messages
2015/08/05
[#70257] [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI — ko1@...
Issue #11420 has been reported by Koichi Sasada.
11 messages
2015/08/06
[#70337] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/11
Nice. Thank you guys for looking into this.
[#70349] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
Btw, did you consider using flexible array to avoid extra malloc
[#70355] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Юрий Соколов <funny.falcon@...>
2015/08/12
I thought to suggest to embed hash_id_table directly into places when it is
[#70356] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— SASADA Koichi <ko1@...>
2015/08/12
On 2015/08/13 4:29, Юрий Соколов wrote:
[#70358] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
SASADA Koichi <ko1@atdot.net> wrote:
[#70509] [Ruby trunk - Misc #11276] [RFC] compile.c: convert to use ccan/list — ko1@...
Issue #11276 has been updated by Koichi Sasada.
3 messages
2015/08/21
[#70639] the undefined behavior of an iterator if it is modified inside of the block to which it yields — Daniel Doubrovkine <dblock@...>
(this is my first time e-mailing list list, so apologies for any misstep :)
4 messages
2015/08/31
[ruby-core:70465] [Ruby trunk - Bug #11466] [Open] Memory leak in win32 fill_random_bytes_syscall
From:
abudovski@...
Date:
2015-08-19 16:25:44 UTC
List:
ruby-core #70465
Issue #11466 has been reported by Alex Budovski.
----------------------------------------
Bug #11466: Memory leak in win32 fill_random_bytes_syscall
https://bugs.ruby-lang.org/issues/11466
* Author: Alex Budovski
* Status: Open
* Priority: Normal
* Assignee:
* ruby -v: master
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
Leak of 608 bytes in this stack:
~~~
+ 608 ( 608 - 0) 1 allocs BackTrace9BD0704B
+ 1 ( 1 - 0) BackTrace9BD0704B allocations
ntdll!RtlpCallInterceptRoutine+40 (d:\blue\minkernel\ntos\rtl\heappriv.h, 3625)
ntdll!RtlAllocateHeap+79836 (d:\blue\minkernel\ntos\rtl\heap.c, 1892)
rsaenh!InitUser+20 (d:\9147\ds\win32\ntcrypto\scp\ntagum.c, 783)
rsaenh!NTagLogonUser+167 (d:\9147\ds\win32\ntcrypto\scp\ntagum.c, 950)
rsaenh!CPAcquireContext+88 (d:\9147\ds\win32\ntcrypto\scp\ntagum.c, 1230)
cryptsp!CryptAcquireContextA+4A3 (d:\9147\ds\win32\ntcrypto\cryptsp\cryptapi.c, 884)
rubyprov!fill_random_bytes_syscall+44 (e:\dev\ruby\random.c, 498)
rubyprov!fill_random_bytes+1D (e:\dev\ruby\random.c, 542)
rubyprov!fill_random_seed+2A (e:\dev\ruby\random.c, 557)
rubyprov!init_randomseed+18 (e:\dev\ruby\random.c, 1446)
rubyprov!Init_RandomSeed+3C (e:\dev\ruby\random.c, 1458)
rubyprov!rb_call_inits+E (e:\dev\ruby\inits.c, 21)
rubyprov!ruby_setup+C6 (e:\dev\ruby\eval.c, 63)
~~~
It looks like the fill_random_bytes_syscall isn't releasing the context on success?
~~~
static int
fill_random_bytes_syscall(void *seed, size_t size)
{
static HCRYPTPROV perm_prov;
HCRYPTPROV prov = perm_prov, old_prov;
if (!prov) {
if (!CryptAcquireContext(&prov, NULL, NULL, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT)) {
prov = (HCRYPTPROV)INVALID_HANDLE_VALUE;
}
old_prov = (HCRYPTPROV)ATOMIC_PTR_CAS(perm_prov, 0, prov);
if (LIKELY(!old_prov)) { /* no other threads acquried */
if (prov != (HCRYPTPROV)INVALID_HANDLE_VALUE) {
rb_gc_register_mark_object(Data_Wrap_Struct(0, 0, release_crypt, &perm_prov));
}
}
else { /* another thread acquried */
if (prov != (HCRYPTPROV)INVALID_HANDLE_VALUE) {
CryptReleaseContext(prov, 0);
}
prov = old_prov;
}
}
if (prov == (HCRYPTPROV)INVALID_HANDLE_VALUE) return -1;
CryptGenRandom(prov, size, seed);
return 0;
}
~~~
--
https://bugs.ruby-lang.org/