That's strange, recovery mode does not change LSan behavior at all. On Wed, Apr 6, 2016 at 4:18 PM, <[email protected]> wrote:
> So, I tried adding the following two options to my benchmark: > > -fsanitize=address -fsanitize-recover=address ASAN_OPTIONS=halt_on_error= > 0 > > > and I ran this a few times to confirm. Unexpectedly, LSAN found *fewer* > leaks than before. Does anyone understand why this may be the case? > > Again, my goal is to find as thorough coverage of leaks as possible. > > Thank you, > Mark > > > > On Tuesday, April 5, 2016 at 5:57:43 PM UTC-4, [email protected] > wrote: >> >> Thanks -- I'll try that. >> >> On Tuesday, April 5, 2016 at 2:51:01 PM UTC-4, Evgeniy Stepanov wrote: >>> >>> ASan has a recover mode, -fsanitize=address -fsanitize-recover=address >>> and then ASAN_OPTIONS=halt_on_error=0. It may be not as well supported >>> as the default mode though. >>> >>> On Tue, Apr 5, 2016 at 9:24 AM, <[email protected]> wrote: >>> > Gotcha. Thank you! >>> > >>> > On Tuesday, April 5, 2016 at 12:02:45 PM UTC-4, Dmitry Vyukov wrote: >>> >> >>> >> On Tue, Apr 5, 2016 at 5:54 PM, <[email protected]> wrote: >>> >> > >>> >> > >>> >> > On Tuesday, April 5, 2016 at 9:40:26 AM UTC-4, Dmitry Vyukov wrote: >>> >> >> >>> >> >> On Tue, Apr 5, 2016 at 3:33 PM, <[email protected]> wrote: >>> >> >> > Hi, I'm running ASAN on a multiprocess workload, specifically an >>> MPI >>> >> >> > program. ASAN seems to handle this fairly well, by printing the >>> >> >> > process >>> >> >> > number at the beginning of each section. However, the outputs >>> from >>> >> >> > each >>> >> >> > process sometimes get overlapped, and the callstacks are >>> therefore >>> >> >> > sometimes >>> >> >> > overlapping a bit. One feature that I would like (which the >>> valgrind >>> >> >> > tools >>> >> >> > have) is to see the output to different log files, one per >>> process. >>> >> >> > One >>> >> >> > way >>> >> >> > this could work is with a --log-file option where the filename >>> is >>> >> >> > specified >>> >> >> > as such: --log-file=asan.%p.out (where %p is filled in with the >>> pid). >>> >> >> > >>> >> >> > I haven't looked at the ASAN source yet, but I did scour the >>> docs and >>> >> >> > it >>> >> >> > doesn't seem like this is available in >>> >> >> > https://github.com/google/sanitizers/wiki/AddressSanitizerFlags >>> >> >> > >>> >> >> > Does this option happen to exist? >>> >> >> >>> >> >> >>> >> >> Hi Mark, >>> >> >> >>> >> >> The flag is log_path. Added it to wiki. >>> >> >> >>> >> >> >>> >> > >>> >> > Hi Dmitry, thank you; this solves this problem. >>> >> > >>> >> >> > Second question: Is it possible to see ASAN output on a >>> per-thread >>> >> >> > level? >>> >> >> > Right now outputs seem to be aggregated on a per-process basis, >>> even >>> >> >> > if >>> >> >> > each >>> >> >> > process has multiple threads. >>> >> >> >>> >> >> No, there is no such option. >>> >> >> Asan terminates process on first error, so what output do you >>> mean? >>> >> > >>> >> > >>> >> > >>> >> > If a given process p has t threads, I'd ideally like to see these >>> the >>> >> > memory >>> >> > issues broken out on a per-thread basis. TSAN labels different >>> threads >>> >> > with >>> >> > T1, T2, T3, etc. to show where race conditions, etc. occur. >>> However, >>> >> > ASAN >>> >> >>> >> You can assign custom names to threads with pthread_setname_np and >>> >> prctl(PR_SET_NAME). >>> >> >>> >> > seems to lump together issues for all threads of a given process. >>> Is >>> >> > there >>> >> > any way to see more detail about which thread had which memory >>> issue? >>> >> > Please >>> >> > note that the only memory issue I have at this point is from LSAN >>> >> > (leaks) -- >>> >> > all other memory issues are fixed for me at this point. >>> >> >>> >> Leaks are not tied to threads. They are process wide. So it is not >>> >> possible to sort them by threads. >>> >> >>> >> For other bugs, like use-after-free, asan will terminate process >>> >> instantly. So there is no question of sorting either. >>> >> >>> >> >>> >> > Additional related question: Assuming the above situation (all ASAN >>> >> > issues >>> >> > other than leaks fixed), and assuming the program runs successfully >>> to >>> >> > the >>> >> > end (correct return code, output, etc.), does LSAN do a full leak >>> check >>> >> > on >>> >> > the entire program before returning its leak report, or does it >>> >> > sometimes >>> >> > exit early? I'm comparing two versions of a program, and one >>> version >>> >> > apparently leaks 70% more memory than the other version. I would >>> like to >>> >> > know if these totals are reliable and representative of the entire >>> >> > program, >>> >> > or if this could simply be due to the fact that LSAN is exiting >>> early in >>> >> > one >>> >> > case. >>> >> >>> >> I don't know. It well can be that lsan has some limit on number of >>> >> reported objects. So if you have lots of leaks, the report will be >>> >> some sampling. But I am not sure. >>> > >>> > -- >>> > 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. > -- 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.
