Just to confirm, I think using lsan allocator simply means don't to implement the custom allocator, but just using the existing APIs to malloc/free to deal with the memory.
I think we can probably do that. The issue is this is some third party code(dpdk.org). We probably have to introduce some lsan only macro in our own patch to bypass their built-in memory management when doing memory leak analysis. Thanks! On Tue, Oct 11, 2016 at 12:21 PM, Maxim Ostapenko <[email protected]> wrote: > Forgot to add Ming to reply. > > 11 Окт 2016 г. 22:35 пользователь "Maxim Ostapenko" <[email protected]> > написал: > >> > >> Hi, >> >> 11 Окт 2016 г. 21:12 пользователь "Ming Zhao" <[email protected]> >> написал: >> > >> > Hi, >> > >> > I'm trying to figure out a way to let a custom allocator be able to >> > report leaked object through lsan. >> > Presumably we could just do everything in the allocator since it's >> > customized already. But we don't really want to repeat the effort that >> > has been done by lsan like tracking the live object, collect the >> > allocation stacktraces, etc. >> > >> >> Well, LSan actually needs to track heap chunks to correctly form reachable >> memory set (see >> https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizerDesignDocument). >> So, you'll need that stuff in either case if you want use LeakSanitizer. >> >> > We are using ASAN_POISON_MEMORY_REGION so that at least we can detect >> > use after free with the custom allocator, but unfortunately it doesn't >> > cover the lsan portion. >> > __lsan_register_root_region/__lsan_unregister_root_region seem to be >> > something close, but somehow lsan doesn't report memory leak even if >> > there is a missing __lsan_unregister_root_region in our test. >> >> That's expected. __lsan_register_root_region just marks given memory >> region as a source of live pointers to LSan memory chunks. Since you are >> using your own allocator, LSan knows nothing about allocated memory chunks >> (see my comment above) and calling >> __lsan_register_root_region/__lsan_unregister_root_region on your memory is >> completely useless. >> >> > Any other hint? Thanks! >> >> FWIW, I suggest you just to use LSan allocator to find memory leaks. >> Otherwise, you'll need to reimplement its memory tracking functionality >> that's might be undesirable. >> >> -Maxim >> >> > >> > - Ming >> > >> > -- >> > 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. -- 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.
