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] <javascript:>> > 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] <javascript:>. > > 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.
