[RFC] [PATCH V1] framework/*: Add function to support ASan test

Tu, Lijuan lijuan.tu at intel.com
Fri Jan 14 11:03:54 CET 2022


> Sent: 2021年12月14日 23:41
> From: Owen Hilyard <ohilyard at iol.unh.edu> 
> To: Dong, JunX <junx.dong at intel.com>
> Cc: dts at dpdk.org; Tu, Lijuan <lijuan.tu at intel.com>; Ling, WeiX <weix.ling at 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.


More information about the dts mailing list