hello
1. can you tell me where is the memory scan in source code?(which file?
which class? which function?)
i read the most lsan source code, but i don't find that scan code : (
2. why 64bit platform is ok? a random 8 byte sequences don't like a pointer?
3. is it possible that we ignore some large malloc memory scan? then we can
reduce missing memory leak percent.
i know it can't make sure all leak will be detect, but sometimes it
will be usefull, right?
after all there is no better tools to detect memory leak on 32bit
platform.
Thanks so much for response : )
在 2014年11月28日星期五UTC+8下午2时06分56秒，Glider写道：
>
> Hello.
>
> The main problem with 32-bit leak checking is that too many random 4-byte
> sequences look like pointers.
> In order to find live objects in the heap LSan scans the memory that's
> already known to be live and looks for pointers in it. Because LSan doesn't
> know anything about data types, it has to aggressively treat everything
> that looks like a pointer as such. This approach may lead to false
> negatives (missing memory leaks), and on 32-bit platforms it actually does.
>
> HTH,
> Alex
> On Nov 28, 2014 5:15 AM, "wuning.shi" <[email protected] <javascript:>>
> wrote:
>
>> hello
>>
>> we want to use lsan on 32 bit arm platform, and i see your explain of the
>> main problem.
>> https://code.google.com/p/address-sanitizer/issues/detail?id=294
>>
>> i have read some source code.
>> but i still can't understand why 64 bit platform has no problem. why lsan
>> need check a 32bit number?
>>
>> can you explain more about lsan design principle please?
>>
>> thanks very much : )
>>
>>
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
