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 KeenanThread Next