Bug 222125 - sysutils/facter exiting in SIGABRT
Summary: sysutils/facter exiting in SIGABRT
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: FreeBSD Puppet Team
: 222217 222751 (view as bug list)
Depends on: 222576
  Show dependency treegraph
Reported: 2017-09-07 17:13 UTC by RyanB
Modified: 2019-01-10 17:52 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description RyanB 2017-09-07 17:13:00 UTC
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.
Comment 1 Bugzilla Automation freebsd_committer 2017-09-07 17:13:00 UTC
Maintainer informed via mail
Comment 2 Romain Tartière freebsd_committer 2017-09-24 20:24:09 UTC
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
Comment 3 Romain Tartière freebsd_committer 2017-09-25 06:24:31 UTC
Assign to maintainers (puppet@)
Comment 4 Romain Tartière freebsd_committer 2017-10-11 07:42:25 UTC
*** Bug 222751 has been marked as a duplicate of this bug. ***
Comment 5 Romain Tartière freebsd_committer 2017-10-11 09:15:21 UTC

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:

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?

Comment 6 Romain Tartière freebsd_committer 2017-10-11 09:26:24 UTC
*** Bug 222217 has been marked as a duplicate of this bug. ***
Comment 7 commit-hook freebsd_committer 2017-10-12 16:53:14 UTC
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

  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

  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

Comment 8 Walter Schwarzenfeld freebsd_triage 2018-10-07 19:04:22 UTC
There are some updates in the meantime. Is there still a problem, or could this be closed?
Comment 9 Romain Tartière freebsd_committer 2019-01-10 17:52:01 UTC
(In reply to w.schwarzenfeld from comment #8)

Just tried and I don't see the problem anymore.  Safe to close I guess, thanks!