|
From: Jeffrey W. <nol...@gm...> - 2011-08-24 04:08:40
|
Hi All, Does anyone have suppression rules for Boost? We're getting overwhelmed with Boost squawks, and we are concerned Boost noise is drowning out problems with our gear. A small sample is below from our run of about 30 self tests. For the full run, there are about 12,000 lines, many which appear to be related to Boost. On a side note, I don't ever recall seeing this many warnings from Valgrind (even when testing large libraries such as Crypto++). Would anyone know if Boost is doing something clever, or are there real problems here (has someone previously investigated)? Jeff ... ==8199== 24 bytes in 1 blocks are still reachable in loss record 147 of 999 ==8199== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261) ==8199== by 0x50D221C: boost::runtime::environment::rt_env_detail::new_var_record(boost::unit_test::basic_cstring<char const>) (new_allocator.h:89) ==8199== by 0x50D2A52: boost::runtime::environment::rt_env_detail::variable_data& boost::runtime::environment::rt_env_detail::init_new_var<bool, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char> >(boost::unit_test::basic_cstring<char const>, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char>) (environment.hpp:54) ==8199== by 0x50BDE39: T.6666 (environment.hpp:113) ==8199== by 0x50BDF63: boost::unit_test::runtime_config::show_build_info() (unit_test_parameters.ipp:395) ==8199== by 0x50B3E16: boost::unit_test::unit_test_log_t::test_start(unsigned long) (unit_test_log.ipp:140) ==8199== by 0x50A8623: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::ut_detail::test_start_caller>::invoke() (framework.ipp:71) ==8199== by 0x509D51D: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (callback.hpp:118) ==8199== by 0x509D59A: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1282) ==8199== by 0x50A5891: boost::unit_test::framework::run(unsigned long, bool) (framework.ipp:413) ==8199== by 0x50B4D42: boost::unit_test::unit_test_main(bool (*)(), int, char**) (unit_test_main.ipp:185) ==8199== by 0x475CC1: main (unit_test.hpp:59) ==8199== ==8199== 24 bytes in 1 blocks are still reachable in loss record 148 of 999 ==8199== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261) ==8199== by 0x50D221C: boost::runtime::environment::rt_env_detail::new_var_record(boost::unit_test::basic_cstring<char const>) (new_allocator.h:89) ==8199== by 0x50D2A52: boost::runtime::environment::rt_env_detail::variable_data& boost::runtime::environment::rt_env_detail::init_new_var<bool, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char> >(boost::unit_test::basic_cstring<char const>, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char>) (environment.hpp:54) ==8199== by 0x50BDE39: T.6666 (environment.hpp:113) ==8199== by 0x50BDFA3: boost::unit_test::runtime_config::catch_sys_errors() (unit_test_parameters.ipp:409) ==8199== by 0x50B7CF2: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:63) ==8199== by 0x50A8940: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (framework.ipp:150) ==8199== by 0x50D7762: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (unit_test_suite.ipp:207) ==8199== by 0x50A5C27: boost::unit_test::framework::run(unsigned long, bool) (framework.ipp:436) ==8199== by 0x50B4D42: boost::unit_test::unit_test_main(bool (*)(), int, char**) (unit_test_main.ipp:185) ==8199== by 0x475CC1: main (unit_test.hpp:59) ==8199== ==8199== 24 bytes in 1 blocks are still reachable in loss record 149 of 999 ==8199== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261) ==8199== by 0x50D221C: boost::runtime::environment::rt_env_detail::new_var_record(boost::unit_test::basic_cstring<char const>) (new_allocator.h:89) ==8199== by 0x50D2A52: boost::runtime::environment::rt_env_detail::variable_data& boost::runtime::environment::rt_env_detail::init_new_var<bool, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char> >(boost::unit_test::basic_cstring<char const>, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char>) (environment.hpp:54) ==8199== by 0x50BDE39: T.6666 (environment.hpp:113) ==8199== by 0x50BDFE3: boost::unit_test::runtime_config::auto_start_dbg() (unit_test_parameters.ipp:418) ==8199== by 0x50B7CFF: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:65) ==8199== by 0x50A8940: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (framework.ipp:150) ==8199== by 0x50D7762: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (unit_test_suite.ipp:207) ==8199== by 0x50A5C27: boost::unit_test::framework::run(unsigned long, bool) (framework.ipp:436) ==8199== by 0x50B4D42: boost::unit_test::unit_test_main(bool (*)(), int, char**) (unit_test_main.ipp:185) ==8199== by 0x475CC1: main (unit_test.hpp:59) ==8199== ==8199== 24 bytes in 1 blocks are still reachable in loss record 150 of 999 ==8199== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261) ==8199== by 0x50D221C: boost::runtime::environment::rt_env_detail::new_var_record(boost::unit_test::basic_cstring<char const>) (new_allocator.h:89) ==8199== by 0x50D2A52: boost::runtime::environment::rt_env_detail::variable_data& boost::runtime::environment::rt_env_detail::init_new_var<bool, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char> >(boost::unit_test::basic_cstring<char const>, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char>) (environment.hpp:54) ==8199== by 0x50BDE39: T.6666 (environment.hpp:113) ==8199== by 0x50BE023: boost::unit_test::runtime_config::use_alt_stack() (unit_test_parameters.ipp:427) ==8199== by 0x50B7D07: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:66) ==8199== by 0x50A8940: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (framework.ipp:150) ==8199== by 0x50D7762: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (unit_test_suite.ipp:207) ==8199== by 0x50A5C27: boost::unit_test::framework::run(unsigned long, bool) (framework.ipp:436) ==8199== by 0x50B4D42: boost::unit_test::unit_test_main(bool (*)(), int, char**) (unit_test_main.ipp:185) ==8199== by 0x475CC1: main (unit_test.hpp:59) ==8199== ==8199== 24 bytes in 1 blocks are still reachable in loss record 151 of 999 ==8199== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261) ==8199== by 0x50D221C: boost::runtime::environment::rt_env_detail::new_var_record(boost::unit_test::basic_cstring<char const>) (new_allocator.h:89) ==8199== by 0x50D2A52: boost::runtime::environment::rt_env_detail::variable_data& boost::runtime::environment::rt_env_detail::init_new_var<bool, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char> >(boost::unit_test::basic_cstring<char const>, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char>) (environment.hpp:54) ==8199== by 0x50BDE39: T.6666 (environment.hpp:113) ==8199== by 0x50BE063: boost::unit_test::runtime_config::detect_fp_exceptions() (unit_test_parameters.ipp:435) ==8199== by 0x50B7D0F: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:67) ==8199== by 0x50A8940: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (framework.ipp:150) ==8199== by 0x50D7762: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (unit_test_suite.ipp:207) ==8199== by 0x50A5C27: boost::unit_test::framework::run(unsigned long, bool) (framework.ipp:436) ==8199== by 0x50B4D42: boost::unit_test::unit_test_main(bool (*)(), int, char**) (unit_test_main.ipp:185) ==8199== by 0x475CC1: main (unit_test.hpp:59) ==8199== ==8199== 24 bytes in 1 blocks are still reachable in loss record 152 of 999 ==8199== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261) ==8199== by 0x50B7D4A: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (shared_count.hpp:87) ==8199== by 0x50A8940: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (framework.ipp:150) ==8199== by 0x50D7762: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (unit_test_suite.ipp:207) ==8199== by 0x50A5C27: boost::unit_test::framework::run(unsigned long, bool) (framework.ipp:436) ==8199== by 0x50B4D42: boost::unit_test::unit_test_main(bool (*)(), int, char**) (unit_test_main.ipp:185) ==8199== by 0x475CC1: main (unit_test.hpp:59) ==8199== ... |
|
From: Tom H. <to...@co...> - 2011-08-24 06:21:02
|
On 24/08/11 05:08, Jeffrey Walton wrote: > Does anyone have suppression rules for Boost? We're getting > overwhelmed with Boost squawks, and we are concerned Boost noise is > drowning out problems with our gear. > > A small sample is below from our run of about 30 self tests. For the > full run, there are about 12,000 lines, many which appear to be > related to Boost. > > On a side note, I don't ever recall seeing this many warnings from > Valgrind (even when testing large libraries such as Crypto++). Would > anyone know if Boost is doing something clever, or are there real > problems here (has someone previously investigated)? The problem is that you've told valgrind to report all memory that is still allocated, but having allocated blocks that are still reachable at the end of the program is perfectly normal in most systems as most people are happy just to let the system discard the remaining memory on process exit rather than try and free it all. So it's not clear that, at least for any of the example messages you posted, there is any problem here. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Jeffrey W. <nol...@gm...> - 2011-08-24 06:36:08
|
Hi Tom, On Wed, Aug 24, 2011 at 2:20 AM, Tom Hughes <to...@co...> wrote: > On 24/08/11 05:08, Jeffrey Walton wrote: > >> Does anyone have suppression rules for Boost? We're getting >> overwhelmed with Boost squawks, and we are concerned Boost noise is >> drowning out problems with our gear. >> >> A small sample is below from our run of about 30 self tests. For the >> full run, there are about 12,000 lines, many which appear to be >> related to Boost. >> >> On a side note, I don't ever recall seeing this many warnings from >> Valgrind (even when testing large libraries such as Crypto++). Would >> anyone know if Boost is doing something clever, or are there real >> problems here (has someone previously investigated)? > > The problem is that you've told valgrind to report all memory that is still > allocated, Ah, ok. I was not aware it was a problem: ==16850== Reachable blocks (those to which a pointer was found) are not shown. ==16850== To see them, rerun with: --leak-check=full --show-reachable=yes > but having allocated blocks that are still reachable at the end > of the program is perfectly normal in most systems as most people are happy > just to let the system discard the remaining memory on process exit rather > than try and free it all. Sloppy programming practices - the same kind of folks who try and free null pointers. We're working on a security library and we need assurances that cleanup is being performed. Cleanup includes zeroizing sensitive, in-memory materials in case the kernel serves up non-cleared pages. These types of vulnerabilities do occur more frequently then one would expect from elite kernel hackers. For example, were patched recently (last week) in by Ubuntu, see USN-1190-1 (http://www.ubuntu.com/usn/usn-1189-1/). > So it's not clear that, at least for any of the example messages you posted, > there is any problem here. Hmmmm... ok. Jeff |