Need to stand up MSAN / ASAN / TSAN test runs

[litghost]

Currently nextpnr has support for building with MSAN / ASAN / TSAN, but MSAN immediately fails with the following error:

==1506074==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x55ac3a in std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::_M_check_len(unsigned long, char const*) const /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_vector.h:1758:6
    #1 0x574d94 in void std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::_M_realloc_insert<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&>(__gnu_cxx::__normal_iterator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/vector.tcc:436:2
    #2 0x7f54f5cb0ae6 in boost::program_options::option_description::set_names(char const*) (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.74.0+0x2eae6)
    #3 0x7f54f5cb1301 in boost::program_options::option_description::option_description(char const*, boost::program_options::value_semantic const*, char const*) (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.74.0+0x2f301)
    #4 0x7f54f5cb1454 in boost::program_options::options_description_easy_init::operator()(char const*, char const*) (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.74.0+0x2f454)
    #5 0x529390 in nextpnr_fpga_interchange::CommandHandler::getGeneralOptions() cat_x/nextpnr/common/command.cc:103:5

SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_vector.h:1758:6 in std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::_M_check_len(unsigned long, char const*) const
Exiting

This appears to be a problem in boost::program_options, but it could also be a usage problem.

To catch these kinds of errors, there should be a CI that builds nextpnr in its various arches, and make sure that it passes in some of the smoke tests. The current Cirrus CI is too slow to support this in a reasonable amount of time, but a GH Actions flow should be able to do this in a reasonable amount of time.

@gatecat FYI

[gatecat]

This seems like a good idea and something I'm happy to look into.

BTW, for generic issues like this, can you create them on the YosysHQ repo in the future so they get better visibility to other contributors?

[litghost]

This seems like a good idea and something I'm happy to look into.

BTW, for generic issues like this, can you create them on the YosysHQ repo in the future so they get better visibility to other contributors?

The issues I'm creating here are part of a simple project board for the FPGA interchange (see https://github.com/orgs/SymbiFlow/projects/22#card-55959026) so that other members of the Symbiflow team can pick up issues when they are free. I'm not sure if issues created on YosysHQ can be added to that project board. Whatever we do here will definitely end up as a PR on YosysHQ once prototyped on the fork.

[gatecat]

As for the specific MSAN issue here, unfortunately the first example of boost program_options is failing with MSAN in exactly the same way for me, so this is definitely a boost issue that we don't have direct control over (other than perhaps trying to report it upstream if it hasn't been reported already.)

The issues I'm creating here are part of a simple project board for the FPGA interchange (see https://github.com/orgs/SymbiFlow/projects/22#card-55959026) so that other members of the Symbiflow team can pick up issues when they are free. I'm not sure if issues created on YosysHQ can be added to that project board. Whatever we do here will definitely end up as a PR on YosysHQ once prototyped on the fork.

Ah, I hadn't seen the cards. That makes more sense then.

[litghost]

As for the specific MSAN issue here, unfortunately the first example of boost program_options is failing with MSAN in exactly the same way for me, so this is definitely a boost issue that we don't have direct control over (other than perhaps trying to report it upstream if it hasn't been reported already.)

I vaguely recall the some sanitizers don't work right unless the whole program is built with them. As an experiment, we should try and build boost::program_options directly with MSAN and see if that's the issue.