On a freshly installed FreeBSD 11.1 amd64 server, facter keeps exiting on SIGABRT. This is installed completely from ports, with all default values accepted for all dependencies. root@fbsd11:/usr/ports/sysutils/facter # gdb facter GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) run Starting program: /usr/local/bin/facter (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 101518] warning: Lowest section in /usr/local/lib/libicudata.so.58 is .hash at 0000000000000120 [New Thread 808416000 (LWP 101518/facter)] Program received signal SIGABRT, Aborted. [Switching to Thread 808416000 (LWP 101518/facter)] 0x0000000803fc350a in thr_kill () from /lib/libc.so.7 (gdb) bt full #0 0x0000000803fc350a in thr_kill () from /lib/libc.so.7 No symbol table info available. #1 0x0000000803fc34db in raise () from /lib/libc.so.7 No symbol table info available. #2 0x0000000803fc3449 in abort () from /lib/libc.so.7 No symbol table info available. #3 0x0000000803691858 in __cxa_call_unexpected (exception=<value optimized out>) at /usr/src/contrib/libcxxrt/exception.cc:1380 No locals. #4 0x0000000801ec2b27 in boost::locale::conv::impl::convert_to<wchar_t> (begin=<value optimized out>, end=<value optimized out>, charset=<value optimized out>, how=<value optimized out>) at memory:2023 No locals. #5 0x0000000801ec22ad in boost::locale::conv::to_utf<wchar_t> (begin=<value optimized out>, end=<value optimized out>, charset=<value optimized out>, how=<value optimized out>) at libs/locale/src/encoding/codepage.cpp:155 No locals. #6 0x0000000801ede701 in boost::locale::util::simple_converter_impl::simple_converter_impl (this=0x808488010, encoding=@0x808429130) at libs/locale/src/util/codecvt_converter.cpp:95 tmp = <value optimized out> buf = 0x7fffffffdb76 "\200" uchar = Error accessing memory address 0xffffffffffffffff: Bad address. I tried anbling all debugging options for dependencies (and removing stripping for facter) in order to get this far. This looks like it might be a devel/boost-libs issue.
Maintainer informed via mail
For the records, and as zleslie@ told you by e-mail, it seems to be a known problem when your locale was not changed from the default. Can you please confirm with us that when you set LC_ALL to C.UTF-8, facter does not suffer from this problem? > env LC_ALL=C.UTF-8 facter
Assign to maintainers (puppet@)
*** Bug 222751 has been marked as a duplicate of this bug. ***
Hi! After further investigation, when facter starts, it initialize the locales through a leatherman helper function: setup_logging_internal(), which in turn call libboost_locale functions. (lldb) bt * thread #1, stop reason = signal SIGBUS: hardware error * frame #0: libboost_locale.so.1.65.1`std::__1::basic_string<wchar_t, boost::locale::conv::impl::convert_to<wchar_t>::char_traits<std::__1::basic_string>, boost::locale::conv::impl::convert_to<wchar_t>::allocator<std::__1::basic_string> > boost::locale::conv::impl::convert_to<wchar_t>(char const*, char const, char const, boost::locale::conv::method_type) [inlined] std::__1::auto_ptr<boost::locale::conv::impl::converter_to_utf<wchar_t> >::~auto_ptr(void) at memory:2023 frame #1: libboost_locale.so.1.65.1`std::__1::basic_string<wchar_t, boost::locale::conv::impl::convert_to<wchar_t>::char_traits<std::__1::basic_string>, boost::locale::conv::impl::convert_to<wchar_t>::allocator<std::__1::basic_string> > boost::locale::conv::impl::convert_to<wchar_t>(begin="\x80", end="", charset=<unavailable>, how=<unavailable>) at codepage.cpp:85 frame #2: libboost_locale.so.1.65.1`std::__1::basic_string<wchar_t, boost::locale::conv::to_utf<wchar_t>::char_traits<std::__1::basic_string>, boost::locale::conv::to_utf<wchar_t>::allocator<std::__1::basic_string> > boost::locale::conv::to_utf<wchar_t>(begin=<unavailable>, end=<unavailable>, charset=<unavailable>, how=<unavailable>) at codepage.cpp:155 frame #3: libboost_locale.so.1.65.1`boost::locale::util::simple_converter_impl::simple_converter_impl(this=0x0000000807688010, encoding=0x0000000807629130) at codecvt_converter.cpp:95 frame #4: libboost_locale.so.1.65.1`boost::locale::util::create_simple_codecvt(std::__1::locale const&, boost::locale::util::create_simple_codecvt::basic_string<char, boost::locale::util::create_simple_codecvt::char_traits<char>, boost::locale::util::create_simple_codecvt::allocator<char> > const&, unsigned int) [inlined] boost::locale::util::simple_codecvt<char>::simple_codecvt(encoding=0x0000000807629130, refs=0) at codecvt_converter.cpp:194 frame #5: libboost_locale.so.1.65.1`boost::locale::util::create_simple_codecvt(in=0x00007ffffffee270, encoding=0x0000000807629130, type=1) at codecvt_converter.cpp:396 frame #6: libboost_locale.so.1.65.1`boost::locale::impl_icu::create_codecvt(in=0x00007ffffffee270, encoding=<unavailable>, type=1) at codecvt.cpp:139 frame #7: libboost_locale.so.1.65.1`boost::locale::impl_icu::icu_localization_backend::install(this=<unavailable>, base=0x00007ffffffee270, category=32, type=1) at icu_backend.cpp:105 frame #8: libboost_locale.so.1.65.1`boost::locale::localization_backend_manager::impl::actual_backend::install(this=<unavailable>, l=<unavailable>, category=<unavailable>, type=<unavailable>) at localization_backend.cpp:145 frame #9: libboost_locale.so.1.65.1`boost::locale::generator::generate(this=<unavailable>, base=<unavailable>, id=<unavailable>) const at generator.cpp:141 frame #10: libboost_locale.so.1.65.1`boost::locale::generator::generate(this=<unavailable>, id=<unavailable>) const at generator.cpp:116 frame #11: libleatherman_locale.so.1.3.0`boost::locale::generator::operator(this=0x00007ffffffee490, id=0x00007ffffffeed00)(std::__1::basic_string<char, boost::locale::generator::operator()::char_traits<char>, boost::locale::generator::operator()::allocator<char> > const&) const at generator.hpp:202 frame #12: libleatherman_locale.so.1.3.0`leatherman::locale::get_locale(id=0x00007ffffffeed00, domain=0x00007ffffffeece8, paths=0x00007ffffffeecc0) at locale.cc:48 frame #13: libfacter.so.3.9.0`setup_logging_internal(os=0x000000000069bb10, use_locale=true) at logging.cc:20 frame #14: libfacter.so.3.9.0`facter::logging::setup_logging(os=0x000000000069bb10) at logging.cc:64 frame #15: facter`main(argc=1, argv=0x00007fffffffeb88) at facter.cc:136 frame #16: 0x0000000000423ebf facter`_start + 383 In frame 14 https://github.com/puppetlabs/facter/blob/master/lib/src/logging/logging.cc#L64 the code attempts to setup the locales with the current LC_* environment, if it fails it resets the LC_* variables to "C", and if it still fails, it last try without LC_* variables. However, in our case, setup_logging_internal() does not raise an exception: instead it just crashes a few layers deeper in some libboost_locale templates. I do not know if the problem is a wrong usage of boost, or a bug in boost itself, but calling `gen(id)` with id == "" in frame 12 is the statement causing this error: https://github.com/puppetlabs/leatherman/blob/master/locale/src/locale.cc#L48 As a woraround, I tried to use the other initialization code when id == "" and facter behaved as expected. Can you please try to following patch and tell us if this is OK for you? https://github.com/smortex/puppet5/commit/e3d24866c5f394b5c3bdcfae056f653e34c932e1.diff
*** Bug 222217 has been marked as a duplicate of this bug. ***
A commit references this bug: Author: romain Date: Thu Oct 12 16:53:01 UTC 2017 New revision: 451907 URL: https://svnweb.freebsd.org/changeset/ports/451907 Log: Woraround crash when LC_* is not set Puppet and MCollective define LC_ALL=C.UTF-8 to avoid this crash, but it's still a problem for many use cases (e.g. cron job storing facts for MCollective). While this does not fix the root cause of the crash that is still under investigation, this makes facter usable regardless of the user's envrionment. PR: 222125 Submitted by: ryanb@honeycomb.net Changes: head/devel/leatherman/Makefile head/devel/leatherman/files/patch-locale_src_locale.cc