Re: bash prints errors for every non-existing command
Bash should probably be compiled with --disable-nls to workaround. More generally this problem is described here: http://sealiesoftware.com/blog/archive/2017/6/5/Objective-C_and_fork_in_macOS_1013.html and here: https://wefearchange.org/2018/11/forkmacos.rst.html and here: https://blog.phusion.nl/2017/10/13/why-ruby-app-servers-break-on-macos-high-sierra-and-what-can-be-done-about-it/ It's not a gettext issue. It's just like calling malloc in a signal handler. Or backtrace to catch that SIGSEGV if you aren't careful. LOL. Thanks. On Thu, Apr 25, 2024 at 2:08 AM Baerenblau via macports-users < macports-users@lists.macports.org> wrote: > Indeed, $LANG is the root cause (any of $LC_* is not set). Unset of $LANG > or LANG=en_US.UTF-8 helps in my environment, setting it to e.g. "C" does > not help. > > At least a workaround :-) > > Issue #41248 was created 10 years ago but it didn't happen for me until I > upgraded to the current or previous Macos version. > > Thanks! > > Am 24.04.24 um 23:42 schrieb Rainer Müller: > > On 24.04.24 18:33, Baerenblau via macports-users wrote: > >> I'm on macOS 14.4.1 (23E224) and continue to experience a long standing > problem with bash from Macports > >> > >> % which bash > >> /opt/local/bin/bash > >> > >> % bash --version > >> GNU bash, Version 5.2.26(1)-release (x86_64-apple-darwin23.2.0) > >> > >> For every command which is not found a error similar error like this is > printed: > >> > >> $ asdf > >> objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in > progress in another thread when fork() was called. > >> objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in > progress in another thread when fork() was called. We cannot safely call it > or ignore it in the fork() child process. Crashing instead. Set a > breakpoint on objc_initializeAfterForkError to debug. > >> Abort trap: 6 > >> > >> Xcode has been installed today. Then MacPorts has been updated to the > latest version, machine is rebooted, issue continues to exist. > > > > This is indeed a very long standing issue: > > https://trac.macports.org/ticket/41248 > > https://trac.macports.org/ticket/68638 > > > > It appears that this crash is actually caused by gettext, when > localizing the error message in the child process forked by bash. > > > > Rainer >
Re: bash prints errors for every non-existing command
Indeed, $LANG is the root cause (any of $LC_* is not set). Unset of $LANG or LANG=en_US.UTF-8 helps in my environment, setting it to e.g. "C" does not help. At least a workaround :-) Issue #41248 was created 10 years ago but it didn't happen for me until I upgraded to the current or previous Macos version. Thanks! Am 24.04.24 um 23:42 schrieb Rainer Müller: On 24.04.24 18:33, Baerenblau via macports-users wrote: I'm on macOS 14.4.1 (23E224) and continue to experience a long standing problem with bash from Macports % which bash /opt/local/bin/bash % bash --version GNU bash, Version 5.2.26(1)-release (x86_64-apple-darwin23.2.0) For every command which is not found a error similar error like this is printed: $ asdf objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in progress in another thread when fork() was called. objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. Abort trap: 6 Xcode has been installed today. Then MacPorts has been updated to the latest version, machine is rebooted, issue continues to exist. This is indeed a very long standing issue: https://trac.macports.org/ticket/41248 https://trac.macports.org/ticket/68638 It appears that this crash is actually caused by gettext, when localizing the error message in the child process forked by bash. Rainer
Re: bash prints errors for every non-existing command
On 24.04.24 18:33, Baerenblau via macports-users wrote: I'm on macOS 14.4.1 (23E224) and continue to experience a long standing problem with bash from Macports % which bash /opt/local/bin/bash % bash --version GNU bash, Version 5.2.26(1)-release (x86_64-apple-darwin23.2.0) For every command which is not found a error similar error like this is printed: $ asdf objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in progress in another thread when fork() was called. objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. Abort trap: 6 Xcode has been installed today. Then MacPorts has been updated to the latest version, machine is rebooted, issue continues to exist. This is indeed a very long standing issue: https://trac.macports.org/ticket/41248 https://trac.macports.org/ticket/68638 It appears that this crash is actually caused by gettext, when localizing the error message in the child process forked by bash. Rainer
Re: bash prints errors for every non-existing command
Is this problem limited to /opt/local/bin/bash or does it also occur with macOS’ (older) /bin/bash? Or other shells like /bin/zsh for that matter? Nils. > Op 24 apr 2024, om 21:20 heeft Saagar Jha het volgende > geschreven: > > This is coming from the Objective-C runtime, which gets upset when used after > fork. My understanding is that some of the C locale (?) code got replaced by > Swift under the hood, which brings in the runtime and it doesn’t like what > bash does. > >> On Apr 24, 2024, at 11:54, Bill Cole >> wrote: >> >> On 2024-04-24 at 12:33:23 UTC-0400 (Wed, 24 Apr 2024 18:33:23 +0200) >> Baerenblau via macports-users >> is rumored to have said: >> >>> Hi, >>> >>> I'm on macOS 14.4.1 (23E224) and continue to experience a long standing >>> problem with bash from Macports >> >> How long-standing? Just on Sonoma? >> >>> % which bash >>> /opt/local/bin/bash >>> >>> % bash --version >>> GNU bash, Version 5.2.26(1)-release (x86_64-apple-darwin23.2.0) >> >> Maybe rebuild this from source on the local machine? 14.4.1 is darwin >> 23.4.0, which *might* cause issues, although it should not, in principle. If >> you are not on an Apple Silicon Mac, you should definitely reinstall bash >> because you want your shell to be native code. >> >>> For every command which is not found a error similar error like this is >>> printed: >>> >>> $ asdf >>> objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in >>> progress in another thread when fork() was called. >>> objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in >>> progress in another thread when fork() was called. We cannot safely call it >>> or ignore it in the fork() child process. Crashing instead. Set a >>> breakpoint on objc_initializeAfterForkError to debug. >>> Abort trap: 6 >>> >>> Xcode has been installed today. Then MacPorts has been updated to the >>> latest version, machine is rebooted, issue continues to exist. >> >> >> Just as another data point: I have never seen anything like this despite >> running bash built using MacPorts for many years. The error message is not >> of a sort that I would expect to come out of bash itself, which I expect >> knows nothing of the Swift and objc runtimes. Also, you *should* be getting >> an error like this: >> >> $ dsfsfs >> bash: dsfsfs: command not found >> >> Guessing based on those observations, I suspect that you may have something >> in your bash environment that is causing this only when an executable file >> is not found in your $PATH because the process of searching for it and >> launching it hit an abort trap without indicating to bash that the command >> does not exist. I would start >> troubleshooting this by minimizing your $PATH (to something like >> '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin') and removing >> or setting to defaults anything in bash's environment that could cause >> something to be done when you are given an interactive prompt or an error, >> i.e. $PROMPT_COMMAND, $PS1, $PS2, etc. Look in your .bash_profile, .bashrc, >> or .profile for anything being set or run that you don't understand. >> >> >> -- >> Bill Cole >> b...@scconsult.com or billc...@apache.org >> (AKA @grumpybozo and many *@billmail.scconsult.com addresses) >> Not Currently Available For Hire
Re: bash prints errors for every non-existing command
This is coming from the Objective-C runtime, which gets upset when used after fork. My understanding is that some of the C locale (?) code got replaced by Swift under the hood, which brings in the runtime and it doesn’t like what bash does. > On Apr 24, 2024, at 11:54, Bill Cole > wrote: > > On 2024-04-24 at 12:33:23 UTC-0400 (Wed, 24 Apr 2024 18:33:23 +0200) > Baerenblau via macports-users > is rumored to have said: > >> Hi, >> >> I'm on macOS 14.4.1 (23E224) and continue to experience a long standing >> problem with bash from Macports > > How long-standing? Just on Sonoma? > >> % which bash >> /opt/local/bin/bash >> >> % bash --version >> GNU bash, Version 5.2.26(1)-release (x86_64-apple-darwin23.2.0) > > Maybe rebuild this from source on the local machine? 14.4.1 is darwin 23.4.0, > which *might* cause issues, although it should not, in principle. If you are > not on an Apple Silicon Mac, you should definitely reinstall bash because you > want your shell to be native code. > >> For every command which is not found a error similar error like this is >> printed: >> >> $ asdf >> objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in >> progress in another thread when fork() was called. >> objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in >> progress in another thread when fork() was called. We cannot safely call it >> or ignore it in the fork() child process. Crashing instead. Set a breakpoint >> on objc_initializeAfterForkError to debug. >> Abort trap: 6 >> >> Xcode has been installed today. Then MacPorts has been updated to the latest >> version, machine is rebooted, issue continues to exist. > > > Just as another data point: I have never seen anything like this despite > running bash built using MacPorts for many years. The error message is not of > a sort that I would expect to come out of bash itself, which I expect knows > nothing of the Swift and objc runtimes. Also, you *should* be getting an > error like this: > >$ dsfsfs >bash: dsfsfs: command not found > > Guessing based on those observations, I suspect that you may have something > in your bash environment that is causing this only when an executable file is > not found in your $PATH because the process of searching for it and launching > it hit an abort trap without indicating to bash that the command does not > exist. I would start > troubleshooting this by minimizing your $PATH (to something like > '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin') and removing > or setting to defaults anything in bash's environment that could cause > something to be done when you are given an interactive prompt or an error, > i.e. $PROMPT_COMMAND, $PS1, $PS2, etc. Look in your .bash_profile, .bashrc, > or .profile for anything being set or run that you don't understand. > > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire
Re: bash prints errors for every non-existing command
On 2024-04-24 at 12:33:23 UTC-0400 (Wed, 24 Apr 2024 18:33:23 +0200) Baerenblau via macports-users is rumored to have said: > Hi, > > I'm on macOS 14.4.1 (23E224) and continue to experience a long standing > problem with bash from Macports How long-standing? Just on Sonoma? > % which bash > /opt/local/bin/bash > > % bash --version > GNU bash, Version 5.2.26(1)-release (x86_64-apple-darwin23.2.0) Maybe rebuild this from source on the local machine? 14.4.1 is darwin 23.4.0, which *might* cause issues, although it should not, in principle. If you are not on an Apple Silicon Mac, you should definitely reinstall bash because you want your shell to be native code. > For every command which is not found a error similar error like this is > printed: > > $ asdf > objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in progress > in another thread when fork() was called. > objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in progress > in another thread when fork() was called. We cannot safely call it or ignore > it in the fork() child process. Crashing instead. Set a breakpoint on > objc_initializeAfterForkError to debug. > Abort trap: 6 > > Xcode has been installed today. Then MacPorts has been updated to the latest > version, machine is rebooted, issue continues to exist. Just as another data point: I have never seen anything like this despite running bash built using MacPorts for many years. The error message is not of a sort that I would expect to come out of bash itself, which I expect knows nothing of the Swift and objc runtimes. Also, you *should* be getting an error like this: $ dsfsfs bash: dsfsfs: command not found Guessing based on those observations, I suspect that you may have something in your bash environment that is causing this only when an executable file is not found in your $PATH because the process of searching for it and launching it hit an abort trap without indicating to bash that the command does not exist. I would start troubleshooting this by minimizing your $PATH (to something like '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin') and removing or setting to defaults anything in bash's environment that could cause something to be done when you are given an interactive prompt or an error, i.e. $PROMPT_COMMAND, $PS1, $PS2, etc. Look in your .bash_profile, .bashrc, or .profile for anything being set or run that you don't understand. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
