On Sun, Oct 13, 2024 at 04:50:48PM +0200, Patrice Dumas wrote: > On Sun, Oct 13, 2024 at 03:30:14PM +0100, Gavin Smith wrote: > > We have had memory errors with setenv in XS code before. > > Might indeed be related, though the issues were much less severe who > knows what could happen on other platforms. > > > I wrote on November 16, 2023 (private mail): > > > > > I found this entry in "man perldelta" for 5.38.0: > > > > > > • Perl is no longer manipulating the "environ" array directly. > > > The > > > variable "PL_use_safe_putenv" has been removed and > > > "PERL_USE_SAFE_PUTENV" is always defined. This means XS > > > modules can > > > now call "setenv" and "putenv" without causing segfaults. [perl > > > #19399 <https://github.com/Perl/perl5/issues/19399>] > > > > > > I don't know the perl internals enought to say whether this is exactly the > > > same problem that we were facing, but it seems to be fixed, anyway. > > > Linked > > > reports seemed similar to the problem we had. > > > > This was in relation to many errors being logged by valgrind. > > > > Do you know what version of Perl is in use? > > Seems to be > perl5: 5.36.3_2
Fixes that come to mind is avoiding calling setenv somehow for versions of Perl older than 5.38. (According to the message above this is dangerous even if it seems to work ok on most of the platforms we test it for.) Unfortunately 5.38 was only released in 2023. Is it just TEXINFO_XS_CONVERT (i.e. currently off by default) code that calls setenv - if so, we could possibly disable this part of the code and keep the other XS code on for older versions of Perl. Hovever, I remember that there was more dependencies on gettext in XS code after the 7.1 release, so this may not be possible. (I'd have to go back to old emails to remember the details - it may have been for the rarely used "object-oriented definition" commands, such as @defcv that used translated strings in their output.) Depending on how much we wanted to fix this there could be other workarounds - could we call into Perl code to get the translated strings and/or to change the environment? We could even have a separate helper program we could run to get the translated string output, although hopefully that would not be necessary. Unfortunately there doesn't seem to be an easy way to access the gettext API without setting environment variables. > > Does this report relate to https://github.com/gnu-texinfo/ci-check? > > Yes. > > > Do you have a more specific link about where to get the build reports? > > https://github.com/gnu-texinfo/ci-check/actions/runs/11289616593/job/31400276091 > Thanks.
