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
From:
James E Keenan via RT
Date:
December 17, 2011 19:17
Subject:
[perl #56500] perl5.10.0: caching environment causes panic in some modules (esp. Term::ReadLine::Gnu)
Message ID:
rt-3.6.HEAD-14510-1324178236-1260.56500-15-0@perl.org
On Tue Jul 01 04:26:25 2008, gawrilow@mail.math.tu-berlin.de wrote:

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

Since https://rt.cpan.org/Public/Bug/Display.html?id=37194 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About