Interesting idea, but I feel it would have very significant overhead. Basically, every time a region of memory is written or deallocated, we would need to scan the previous contents for anything that looks like a heap pointer and update metadata for those allocations. No need to track references - we are only interested in the most recently overwritten pointer.
Could be a fun experiment. It will definitely slow down execution a lot, but usability benefits could be huge. On Thu, Aug 17, 2017 at 5:05 PM, Eric Feng <efe...@gmail.com> wrote: > Hi, > > For a memory leak, the current implementation of Leak Sanitizer (LSAN) > reports in the code only the place where memory is dynamically allocated, > but not where the actual leak happens. This make it sometimes difficult to > locate the leak in a large complex program. One solution is to extend LSAN > to track references to dynamically allocated blocks, so it can report both > places (where memory is allocated and where it’s lost) for a memory leak. > > I wonder if this idea has ever been brought up or discussed before? If yes, > what's the reason for not not doing it. I understand doing so would require > compiler instrumentation in addition to linking with the special LSAN > library. > > Thanks, > -Eric Feng > > -- > 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 address-sanitizer+unsubscr...@googlegroups.com. > 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 address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
