[BUG] OpenBSD: Program aborts when LANG is not set

[imwints]

The program aborts in when the environment variable LANG is empty. The try-catch block around it doesn't catch the excpetion

To reproduce:
LANG= ./btop

Since a locale could not be detected the program should exit with a proper message, instead the program aborts.

btop-1.3.0
eg++-11.2.0
OpenBSD-7.4 x86_64

Reading symbols from bin/btop...
[New process 102693]
Core was generated by `btop'.
Program terminated with signal SIGABRT, Aborted.
(gdb) bt
#0  thrkill () at /tmp/-:3
#1  0x2c1c1833ae0aee1c in ?? ()
#2  0x000009c5aeb9deb2 in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#3  0x000009c552fd8ea0 in uw_init_context_1 (context=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, context@entry=0x6fc92a587fd0, 
    outer_cfa=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, outer_cfa@entry=0x6fc92a588380, 
    outer_ra=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libgcc/unwind-pe.h:88
#4  0x000009c552fd8609 in _Unwind_RaiseException (exc=0x9c5f7424b00) at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libgcc/unwind.inc:93
#5  0x000009c552ec1444 in __cxxabiv1::__cxa_throw (obj=<optimized out>, tinfo=0x9c552fe7de0 <typeinfo for std::runtime_error>, dest=0x9c552edc7e0 <std::runtime_error::~runtime_error()>)
    at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libstdc++-v3/libsupc++/eh_throw.cc:90
#6  0x000009c552eef99a in std::__throw_runtime_error (__s=__s@entry=0x9c552e3b758 "locale::facet::_S_create_c_locale name not valid")
    at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libstdc++-v3/src/c++11/functexcept.cc:106
#7  0x000009c552ee67d0 in std::locale::facet::_S_create_c_locale (__cloc=@0x6fc92a588420: 0x0, __s=__s@entry=0x9c58e93ad20 "LC_CTYPE=C.UTF-8;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C")
    at c++locale.cc:246
#8  0x000009c552edae60 in std::locale::_Impl::_Impl (this=0x9c58e91c000, __s=0x9c58e93ad20 "LC_CTYPE=C.UTF-8;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C", __refs=<optimized out>)
    at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libstdc++-v3/src/c++98/localename.cc:194
#9  0x000009c552edc056 in std::locale::locale (this=0x6fc92a5885c0, __s=<optimized out>) at /usr/obj/ports/gcc-11.2.0/build-amd64/x86_64-unknown-openbsd7.4/libstdc++-v3/include/bits/basic_string.h:2319
#10 0x000009c3289da5da in main ()

[lcheylus]

No issue when compiling btop with clang++ (OpenBSD current/amd64):

$ clang -v
OpenBSD clang version 16.0.6
Target: amd64-unknown-openbsd7.4
Thread model: posix
InstalledDir: /usr/bin

$ gmake CXX=clang++
(...)
Linking and optimizing binary...
100% -> bin/btop                      (1.8MiB) (45s)

Build complete in (01m:43s)

$ LANG= bin/btop
ERROR: No UTF-8 locale detected!
Use --utf-force argument to force start if you're sure your terminal can handle it.

[imwints]

I'm curios how you managed to compile it with clang. Like I would expect my gmake CXX=clang++-16 tells me that a few c++20 headers cannot be found, since the standard library should be too old. also my default clang is 13.0.0 and not 16.0.6, which I installed as a port.

$ clang -v
OpenBSD clang version 13.0.0
Target: amd64-unknown-openbsd7.4
Thread model: posix
InstalledDir: /usr/bin

$ clang-16 -v
clang version 16.0.6
Target: amd64-unknown-openbsd7.4
Thread model: posix
InstalledDir: /usr/local/llvm16/bin

Is 7.4 != CURRENT ?

[lcheylus]

Yes, I'm running on OpenBSD-current (!= version 7.4): clang v16 installed via ports and libc++ updated by robert@ to support C++23 => https://marc.info/?l=openbsd-cvs&m=170626964703685&w=2

With that, I can compile btop with clang++ :)

I have also proposed a port for sysutils/btop for version 1.3.0 => https://marc.info/?l=openbsd-ports&m=170635392519643&w=2

[imwints]

Ok good to know that llvm is not effected. This is still a problem since to detect the locale an exception got thrown that wasn't caught by the surrounding catch block. So the program logic is correct, just the exception handling doesn't work properly.

Since you are running a newer version, could you try to reproduce this with gcc? This might be worth reporting.