Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need to stand up MSAN / ASAN / TSAN test runs #238

Open
litghost opened this issue Mar 1, 2021 · 4 comments
Open

Need to stand up MSAN / ASAN / TSAN test runs #238

litghost opened this issue Mar 1, 2021 · 4 comments

Comments

@litghost
Copy link

litghost commented Mar 1, 2021

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

@litghost litghost added this to To Do in FPGA interchange bootstrapping via automation Mar 1, 2021
@gatecat
Copy link

gatecat commented Mar 1, 2021

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
Copy link
Author

litghost commented Mar 1, 2021

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
Copy link

gatecat commented Mar 2, 2021

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
Copy link
Author

litghost commented Mar 2, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants