On 5/3/24 10:31 PM, Tom wrote:
That report has a work-around invoking a syntax error which presumably calls out to `setlocale`/`gettext` pre-`fork`, caching the result somewhere (`bash` or `gettext`?) such that the offending call post-`fork` on an unknown command doesn't trigger this issue.That feels brittle; a more general approach might be to move both invocations either side of the fork (as alluded to by the [gettext maintainer][2]), which for `bash` probably means calling `gettext` before `fork`. [1]: https://trac.macports.org/ticket/68638 [2]: https://lists.gnu.org/archive/html/bug-gettext/2024-05/msg00001.html
This seems like a completely Apple-specific problem, since the API
documentation doesn't mention threading, and bash doesn't use any threads
anywhere else. So let's see if we can devise an Apple-specific solution.
It looks like it's the call to setlocale() that creates the auxiliary
threads, and the call to gettext() that forces the artificial crash. Bash
always calls setlocale() as part of initialization, but may not call
gettext() until it has to print a translatable message. So any call to
gettext() in the parent process before any fork would be sufficient to
complete the initialization? I can certainly add a dummy call to gettext()
somewhere, or even a call to initialize and cache the translation of
"command not found" (for instance).
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
