2009/11/11 Dan Kegel :
> On Mon, Nov 9, 2009 at 2:12 PM, Rob Shearman wrote:
>> 2009/11/9 Dan Kegel :
>>> 16 bytes in 1 blocks are definitely lost in loss record 123 of 728
>>> at RtlAllocateHeap (heap.c:1423)
>>> by RtlAllocateAndInitializeSid (sec.c:156)
>>> by NtQueryInformationToken (nt.
On Mon, Nov 9, 2009 at 2:12 PM, Rob Shearman wrote:
> 2009/11/9 Dan Kegel :
>> 16 bytes in 1 blocks are definitely lost in loss record 123 of 728
>> at RtlAllocateHeap (heap.c:1423)
>> by RtlAllocateAndInitializeSid (sec.c:156)
>> by NtQueryInformationToken (nt.c:379)
>> by GetTokenInforma
2009/11/9 Dan Kegel :
> I've never used the security apis, so I'm pretty unfamiliar with them.
> Valgrinding chromium's sandbox_unittests.exe shows the leak
>
> (I think the code leaks token_handle, but fixing
> that doesn't get rid of the reported leak.)
token_handle does not leak -- access_token
2009/11/9 Dan Kegel :
> I've never used the security apis, so I'm pretty unfamiliar with them.
> Valgrinding chromium's sandbox_unittests.exe shows the leak
>
> 16 bytes in 1 blocks are definitely lost in loss record 123 of 728
> at RtlAllocateHeap (heap.c:1423)
> by RtlAllocateAndInitializeSid
I've never used the security apis, so I'm pretty unfamiliar with them.
Valgrinding chromium's sandbox_unittests.exe shows the leak
16 bytes in 1 blocks are definitely lost in loss record 123 of 728
at RtlAllocateHeap (heap.c:1423)
by RtlAllocateAndInitializeSid (sec.c:156)
by NtQueryInfor
