Thanks to the patches shared by Benoit Ganne on September 9, I was able to use AddressSanitizer for vpp. AddressSanitizer detected a problem that I think is caused by a bug in plugins/dpdk/device/init.c related to how the conf->eal_init_args vector is manipulated in the dpdk_config function.

It appears that the code there uses two different kinds of strings, both C-style null-terminated strings (char*) and vectors of type (u8*) which are not necessarily null-terminated but instead have their length stored in a different way (as described in vppinfra/vec.h).

In the dpdk_config function, various strings are added to the conf->eal_init_args vector. Those strings need to be null-terminated because they are later used as input to the "format" function which expects null-terminated strings for its later arguments. The strings are mostly null-terminated but not all of them, which leads to the error detected by AddressSanitizer.

I think what happens is that some string that was generated by the "format" function and is thus not null-terminated is later given as input to a function that needs null-terminated strings as input, leading to illegal memory access.

I'm able to make AddressSanitizer happy by making the following two changes:

(1) Null-terminate the tmp string for conf->nchannels in the same way as it is done in other places in the code:

• tmp = format (0, "%d", conf->nchannels);
  + tmp = format (0, "%d%c", conf->nchannels, 0);

(2) Null-terminate conf->eal_init_args_str before the call to dpdk_log_warn:

+ vec_add1(conf->eal_init_args_str, 0);

After that, vpp starts without complaints from AddressSanitizer.

A nicer way to fix this may be to use the vec_terminate_c_string macro that safely adds c-string termination to a vector:
https://docs.fd.io/vpp/19.08/db/d65/vec_8h.html#a2bc43313bc727b5453c3e5d7cc57a464