develooper Front page | perl.perl5.porters | Postings from December 2011

[perl #56500] perl5.10.0: caching environment causes panic in some modules (esp. Term::ReadLine::Gnu)

Thread Next
James E Keenan via RT
December 17, 2011 19:17
[perl #56500] perl5.10.0: caching environment causes panic in some modules (esp. Term::ReadLine::Gnu)
Message ID:
On Tue Jul 01 04:26:25 2008, wrote:

> This bug has already been submitted by somebody else at,
> ticket #37194, but without further analysis.  The true reason for the
>    failure
> lies in perl core, not in the Term::ReadLine::Gnu module.

Since has been
resolved by Term::ReadLine::Gnu's maintainer, I wonder whether there are
still outstanding issues in this RT.

> At the very beginning, perl makes a copy of the environment and sets
>    the global
> variable environ to point to it.  Each environment string is allocated
>    with perl's own
> safesysmalloc.
> Later on, the initialization routine of the GNU readline library
>    rl_initialize
> modifies the environment variables LINES and COLUMNS.  Obviously, it
>    does not know
> anything about perl's memory management and uses the normal
>    free/malloc.
> During the global destruction perl tries to free the copies of the
>    environment strings;
> when it proceeds with the LINES or COLUMNS, it recognizes the lack of
>    the hidden header
> in front of the string and issues a panic() call.
> In the documentation of the GNU readline library I didn't find any
>    suggestions how to suppress
> the environment modification; even if there were some possibility to
>    do this, there are surely
> a lot of other C/C++ libraries with perl wrappers, which might try to
>    modify the environment.
> On the other hand, no perl module has a chance to prevent environment
>    caching, as the only flag
> controlling this (PL_use_safe_putenv) is read off much earlier during
>    the initial bootstrapping.
> I'd suggest to give up the environment caching at all, or make it
>    optional, on behalf and under
> full responsibility of the user.
> An alternative solution could be a pair of routines to be called from
> each suspicious wrapper module, the first one restoring the original
>    environment and the second one
> checking it for updated strings and reallocating them using perl's
>    memory management.
> But it seems me very hard to guarantee that every module's author will
>    really use it.

Do people feel there is a real problem here?  If so, would either of the
original poster's suggestions prove beneficial?

Thank you very much.
Jim Keenan

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About