From occitan@t-online.de

This is a bug report for perl from occitan@​esperanto.org,
generated with the help of perlbug 1.35 running under perl v5.8.7.

Using Term​::ReadLine​::Gnu the assignment to ENV gives​:

$ perl -MTerm​::ReadLine -e 'new Term​::ReadLine; $ENV{GOGO1} = "fffff"'
Out of memory!

Term​::ReadLine​::Gnu was compiled the official way. We actually found
this bug with a big Swig generated Library. There it is enough to
invoke DynaLoader's bootstrap before assigning to %ENV to trigger this
error. Our own library was compiled by picking the relevant stuff out
of %Config.

In both cases we definitely used the Perl executable described below,
both for the build and the execution. However I tried doing the same
thing (-M and call a function to trigger autoloading) with many of the
standard Modules which require DynaLoader, and none had this bug.

Some versions of our evolving own library have this, and others do not.
But a given setup will reproducably give this error. Unlike the %ENV
extract perlbug generated, here is the exact env I have whittled this
down to. For the example above, it doesn't matter what is in the
variables, but if I unset one more, the error goes away​:

$ env
A=
B=
C=
HOME=/home/dpfeiff
PATH=/usr/local/bin​:/bin​:/usr/bin
TERM=xterm
$ uname -a
SunOS fraurauscher1 5.10 Generic_118833-03 sun4u sparc
SUNW,Sun-Fire-V890

We strongly think that we once had this with ActiveState Perl, but
cannot easily verify that, since we have since migrated to a self
compiled one.

Flags​:
  category=library
  severity=critical

Site configuration information for perl v5.8.7​:

Summary of my perl5 (revision 5 version 8 subversion 7) configuration​:
  Platform​:
  osname=solaris, osvers=2.10, archname=sun4-solaris
  uname='sunos 5.10 s10_60 sun4u sparc sunw,ultra-5_10 '
  config_args='-Dcc=gcc -B/usr/ccs/bin/'
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
  useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
  use64bitint=undef use64bitall=undef uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='gcc -B/usr/ccs/bin/', ccflags ='-fno-strict-aliasing -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O',
  cppflags='-fno-strict-aliasing -pipe -I/usr/local/include'
  ccversion='', gccversion='2.95.3 20010315 (release)',
gccosandvers='solaris2.10'
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='gcc -B/usr/ccs/bin/', ldflags =' -L/usr/local/lib '
  libpth=/usr/local/lib /usr/lib /usr/ccs/lib
  libs=-lsocket -lnsl -ldl -lm -lc
  perllibs=-lsocket -lnsl -ldl -lm -lc
  libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
  cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'

Locally applied patches​:
 

@​INC for perl v5.8.7​:
  /usr/local/lib/perl5/5.8.7/sun4-solaris
  /usr/local/lib/perl5/5.8.7
  /usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris
  /usr/local/lib/perl5/site_perl/5.8.7
  /usr/local/lib/perl5/site_perl
  .

Environment for perl v5.8.7​:
  HOME=/home/dpfeiff
  LANG (unset)
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/usr/local/bin​:/bin​:/usr/bin
  PERL_BADLANG (unset)
  SHELL (unset)

From @rgs

occitan@​t-online.de wrote​:

Using Term​::ReadLine​::Gnu the assignment to ENV gives​:

$ perl -MTerm​::ReadLine -e 'new Term​::ReadLine; $ENV{GOGO1} = "fffff"'
Out of memory!

I don't reproduce this on linux, either with 5.8.7, 5.8.8 or bleadperl,
with a similar configuration (no threads, usemymalloc=n) with and
without Term​::ReadLine​::Gnu installed. Maybe I missed something.

The RT System itself - Status changed from 'new' to 'open'

From occitan@esperanto.org

la 28.06.2006 11​:32 Rafael Garcia-Suarez via RT skribis​:

occitan@​t-online.de wrote​:

Using Term​::ReadLine​::Gnu the assignment to ENV gives​:

$ perl -MTerm​::ReadLine -e 'new Term​::ReadLine; $ENV{GOGO1} = "fffff"'
Out of memory!

I don't reproduce this on linux, either with 5.8.7, 5.8.8 or bleadperl,
with a similar configuration (no threads, usemymalloc=n) with and
without Term​::ReadLine​::Gnu installed. Maybe I missed something.
Nor do I, only on Solaris. IIRC, when building perl myself many years
ago, I was given a choice of DynaLoad mechanisms and had a hard time to
get it running. Since the contents of the loaded library decide whether
this happens or not, maybe there is some memory overwriting happening,
the effect of which depends on the precise layout of the library -- and
probably on the dl mechanism.

I also forgot to mention that I trussed (that's strace for Linuxers) the
programm, and no system calls were failing (besides a few irrelevant
ENOENTs while searching for files). So that would suggest that an
internal malloc wrapper is failing.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

--
lerne / learn / apprends / lär dig / ucz się Esperanto​:
  http​://lernu.net / http​://ikurso.net

From @rgarcia

On 28/06/06, Daniel Pfeiffer <dapfy@​t-online.de> wrote​:

I also forgot to mention that I trussed (that's strace for Linuxers) the
programm, and no system calls were failing (besides a few irrelevant
ENOENTs while searching for files). So that would suggest that an
internal malloc wrapper is failing.

But your perl uses the system's malloc. (like mine)
You could try to compile a perl configured with -Dusemymalloc to see
if you have the same problem with perl's builtin malloc.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn

Cordialement,
--

From dapfy@t-online.de

Well, due to the loading of binary libs we have to have the identical perl in dev, test and production, which is pretty much beyond our control :-( That's why we moved away from ActiveState, which for esoteric reasons is not tolerated as a production platform...

The thing is that this error seems to be a moving target, so it's dissapperance would only prove that we are currently not seeing it. And if it comes back later, once we're in production, it would really bite us.

We have tried debugging it, but it's a stripped perl, which is not very helpful. If you think you could make something out of it on Sparc Solaris, I could send you the perl and its libs.

From dapfy@t-online.de

Hi,

In trying to get a different tack at this problem, instead of our
homebuilt one, I just installed
ActivePerl-5.8.8.817-sun4-solaris-2.6-cc-257965 to ~/perl. When trying
to install Term​::ReadLine​::Gnu to it, I already get the out of memory in
one of the tests.

If I install it nevertheless, the test I originally posted also gives
this error. So it's not the build method (our perl is definitely not
binary compatible with ActiveState's, so they must have some different
compiler
options) nor the version, as we get this on 5.8.7 and 5.8.8.

Since ActiveState is not compiled for debug either, I compiled 5.8.8
from scratch with default options (but for debug and prefix). As I had
feared, the error went away. Just to double check, I rebuilt 5.8.8 from
scratch once more without debug. Still no error.

So it seems that it is possible to compile perl in such a way that even
a Makefile.PL based installation leads to a broken DynaLoader. This bug
has cost us a lot of time, so it would be great if somebody could figure
out from my posted (or ActiveState's) perl -V output, how things can go
so broken! We're fine now, but others might fall into the same trap.

best regards
Daniel

-----Original Message-----
Date​: Thu, 29 Jun 2006 15​:38​:59 +0200
Subject​: Re​: [perl #39647] DynaLoader corrupts %ENV
From​: "dapfy@​t-online.de" <dapfy@​t-online.de>
To​: perlbug-followup@​perl.org

Well, due to the loading of binary libs we have to have the identical
perl in dev, test and production, which is pretty much beyond our
control :-( That's why we moved away from ActiveState, which for
esoteric reasons is not tolerated as a production platform...

The thing is that this error seems to be a moving target, so it's
dissapperance would only prove that we are currently not seeing it. And
if it comes back later, once we're in production, it would really bite
us.

We have tried debugging it, but it's a stripped perl, which is not very
helpful. If you think you could make something out of it on Sparc
Solaris, I could send you the perl and its libs.

p5p@spam.wizbit.be - Status changed from 'open' to 'stalled'

Given the age of this case, I recommend this case be closed as not reproducible. The reporter's email isn't even reachable at this point.