From: "Tu, Lijuan" <lijuan.tu@intel.com>
To: Owen Hilyard <ohilyard@iol.unh.edu>, "Dong, JunX" <junx.dong@intel.com>
Cc: "dts@dpdk.org" <dts@dpdk.org>, "Ling, WeiX" <weix.ling@intel.com>
Subject: RE: [RFC] [PATCH V1] framework/*: Add function to support ASan test
Date: Fri, 14 Jan 2022 10:03:54 +0000 [thread overview]
Message-ID: <282c3927290f4e32bb893f6119f5777c@intel.com> (raw)
In-Reply-To: <CAHx6DYCTq-n533V=SEM5KyXovvRA-s7vES9W-nmjZkLrAHaEVg@mail.gmail.com>
> Sent: 2021年12月14日 23:41
> From: Owen Hilyard <ohilyard@iol.unh.edu>
> To: Dong, JunX <junx.dong@intel.com>
> Cc: dts@dpdk.org; Tu, Lijuan <lijuan.tu@intel.com>; Ling, WeiX <weix.ling@intel.com>
> Subject: Re: [RFC] [PATCH V1] framework/*: Add function to support ASan test
>
> Am I missing where this is disabled for performance tests? Both ASAN and
> LSAN have a large performance impact, especially in any code that allocates
> a lot of memory. I have no objections to using this in functional testing,
> since performance doesn't matter that much there.
Sure, performance tests don't use it, actually functional testing also have
choice, It only take effective while launching dts with '--asan'
> I also can't tell if this changes the json output for a test suite. If an
> asan failure does not cause a test case/suite to fail, (which I think it
> should), then we need to have that information available in
> test_results.json, probably as a new key under the per-crb output. If an
> asan failure does cause the test case/suite to fail, then I don't think we
> need extra output.
Asan failures sometimes cause cases/suites failure, sometimes not. Some guys
would care about the cases/suites failure, and some guys would care about the
asan failure. That's why we adding a new result file for asan, but not replace
the current one.
> Finally, I think the config file needs to describe all of the options and
> what their valid values are, nic_single_core_perf.cfg is a good example of
> this.
Agree that, also we need a guides.
> Also, I would prefer to avoid embedding json in the config files if
> possible, and I think that we might be able to have the start and end
> values for each of the sanitizers be stored as a pair, so we would have
> something like this:
>
> lsan_bounds=LeakSanitizer, SUMMARY
> asan_bounds=AddressSanitizer, SUMMARY
>
> That would avoid needing to use json parsing and you could just access by
> index.
I am considering to add more sanitizers easily for users, so we are going have
something as following.
filter_bounds=LeakSanitizer:SUMMARY,AddressSanitizer:SUMMARY
It separates different sanitizers by comma, and pair start and end by colon.
next prev parent reply other threads:[~2022-01-14 10:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-10 9:57 Dong JunX
2021-12-14 15:40 ` Owen Hilyard
2022-01-14 10:03 ` Tu, Lijuan [this message]
2022-01-14 13:44 ` Owen Hilyard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=282c3927290f4e32bb893f6119f5777c@intel.com \
--to=lijuan.tu@intel.com \
--cc=dts@dpdk.org \
--cc=junx.dong@intel.com \
--cc=ohilyard@iol.unh.edu \
--cc=weix.ling@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).