From chaoxianli@micron.com

This is a bug report for perl from chaoxianli@​micron.com,
generated with the help of perlbug 1.39 running under perl 5.10.1.

#!/mu/bin/perl
###########
#Issue Report​:
#We have a perl application running on SUN Solaris for quite sometime without any problem
#Recently we tried to migrate it to Linux platform. It could not run successfully
#A Strange thing was noticed that the very first child process could always run successfully, but the following child processes would encounter error
#The error is about GD​::Simple module, like​:
#unknown color at /mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/GD/Simple.pm line 802, <DATA> line 57.
#unknown color at /mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/GD/Simple.pm line 802.
#however, if we stop using fork and just use a simple loop it will be able to run successfully by calling GD​::Simple module multiple times
#So, the problem should not be on GD​::Simple
#We narrowed down with the below testing case which could reproduce the issue.
#Its output​:
#
#Wait for Child 0 to finish​: 0
#START CHILD​: 0
#initializeMapImg end
#END CHILD​: 0
#Wait for Child to finish​: 1
#START CHILD​: 1
#initializeMapImg start
#unknown color at /mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/GD/Simple.pm line 802, <DATA> line 54.
#Wait for Child to finish​: 2
#START CHILD​: 2
#initializeMapImg start
#unknown color at /mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/GD/Simple.pm line 802.
#Exit​: 3
#
#We suspect the first child process somewhow corrupted the parent memory which caused the following child processes failed because of corrupted parent memory copied to each child
#
#Our system info​:
#/mu/bin/perl -v
#This is perl 5, version 12, subversion 2 (v5.12.2) built for x86_64-linux-thread-multi
#uname -a
#Linux amklprobedev02 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22​:19​:54 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
#
###########
use strict;
use CGI qw/​:standard/;
use File​::Path;
use GD​::Simple;
use POSIX qw[ _exit ];
use POSIX "​:sys_wait_h";

my $PrcCnt=0;
my $cid;

while ($PrcCnt < 3) {
  my $prcId = fork();

  if ($prcId > 0) {
  do {
  $cid = waitpid($prcId, WNOHANG);
  print "\nWait for Child to finish​: $PrcCnt"."\n";
  sleep 1;
  } while $cid >0;
  $PrcCnt++;
  } elsif (defined $prcId) {
  print "\nSTART CHILD​: $PrcCnt"."\n";
  print "\ninitializeMapImg start"."\n";
  my $img = &initializeMapImg();
  print "\ninitializeMapImg end"."\n";
  print "\nEND CHILD​: $PrcCnt"."\n";
  POSIX​::_exit(0);
  }
}
print "\nExit​: $PrcCnt"."\n";
exit 0;
 
#=========================================================================================================================
sub initializeMapImg {
 
  my $WfImgSize = 750;
  my $WfPxlSize = $WfImgSize - 50;
  my $WfDieOffset = 10;
  my $BinLegendaSize = 150;

  my $img = GD​::Simple->new($WfImgSize + $BinLegendaSize, $WfImgSize);
 
  $img->bgcolor(undef);
  $img->fgcolor('black');
  $img->rectangle(0, 0, $WfImgSize + $BinLegendaSize - 1, $WfImgSize - 1);

  return ($img);

}

Flags​:
  category=core
  severity=high

This perlbug was built using Perl 5.10.1 in the Fedora build system.
It is being executed now by Perl 5.10.1 - Wed Aug 7 06​:30​:39 EDT 2013.

Site configuration information for perl 5.10.1​:

Configured by Red Hat, Inc. at Wed Aug 7 06​:30​:39 EDT 2013.

Summary of my perl5 (revision 5 version 10 subversion 1) configuration​:
 
  Platform​:
  osname=linux, osvers=2.6.18-348.12.1.el5, archname=x86_64-linux-thread-multi
  uname='linux x86-007.build.bos.redhat.com 2.6.18-348.12.1.el5 #1 smp mon jul 1 17​:54​:12 edt 2013 x86_64 x86_64 x86_64 gnulinux '
  config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DDEBUGGING=-g -Dversion=5.10.1 -Dmyhostname=localhost -Dperladmin=root@​localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Darchlib=/usr/lib64/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Dvendorarch=/usr/lib64/perl5/vendor_perl -Dinc_version_list=5.10.0 -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -U
d_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=define, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic',
  cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.4.7 20120313 (Red Hat 4.4.7-3)', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='gcc', ldflags =' -fstack-protector'
  libpth=/usr/local/lib64 /lib64 /usr/lib64
  libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
  perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
  libc=, so=so, useshrplib=true, libperl=libperl.so
  gnulibc_version='2.12'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'

Locally applied patches​:
 

@​INC for perl 5.10.1​:
  /usr/local/lib64/perl5
  /usr/local/share/perl5
  /usr/lib64/perl5/vendor_perl
  /usr/share/perl5/vendor_perl
  /usr/lib64/perl5
  /usr/share/perl5
  .

Environment for perl 5.10.1​:
  HOME=/home/fmgfmg
  LANG=en_US.UTF-8
  LANGUAGE (unset)
  LD_LIBRARY_PATH=/oracle/client10g/lib
  LOGDIR (unset)
  PATH=/usr/lib64/qt-3.3/bin​:/usr/local/bin​:/bin​:/usr/bin​:/home/fmgfmg/bin​:/oracle/client10g/bin
  PERL_BADLANG (unset)
  SHELL=/bin/sh

From @tonycoz

On Tue Jun 02 20​:23​:45 2015, chaoxianli@​micron.com wrote​:

#We have a perl application running on SUN Solaris for quite sometime
without any problem
#Recently we tried to migrate it to Linux platform. It could not run
successfully
#A Strange thing was noticed that the very first child process could
always run successfully, but the following child processes would
encounter error
#The error is about GD​::Simple module, like​:
#unknown color at /mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/GD/Simple.pm
line 802, <DATA> line 57.
#unknown color at /mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/GD/Simple.pm
line 802.

This is a bug (or perhaps limitation) in GD​::Simple.

GD​::Simple loads its color table from the DATA file handle, and since
handle positions are shared between parents and their forked children
the first child manages to successfully load the color table.

When the second child tries however, the position of the DATA handle is already past the end of the color table and so no data is loaded
into the %COLORS hash, and the lookup fails.

You can avoid this by calling​:

  GD​::Simple->read_color_table;

before the first fork, or if you prefer not to call an undocumented
function​:

  GD​::Simple->color_names;

which will load the color table so the children don't need to.

Marking this ticket as rejected, this isn't a bug in perl.

Tony

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

@tonycoz - Status changed from 'open' to 'rejected'

From chaoxianli@micron.com

Tony,

Thanks for the quick response and the possible solutions provided. Just a quick question, why the same code that running on the SUN Solaris was not affected by the GD​::Simple module?

Best Regards,

Chao Xian

-----Original Message-----
From​: Tony Cook via RT [mailto​:perlbug-followup@​perl.org]
Sent​: 03 June, 2015 2​:24 PM
To​: Chao Xian Li (chaoxianli)
Subject​: [perl #125316] Forked Child Process Corrupted Parent Memory

On Tue Jun 02 20​:23​:45 2015, chaoxianli@​micron.com wrote​:

#We have a perl application running on SUN Solaris for quite sometime
without any problem #Recently we tried to migrate it to Linux
platform. It could not run successfully #A Strange thing was noticed
that the very first child process could always run successfully, but
the following child processes would encounter error #The error is
about GD​::Simple module, like​:
#unknown color at /mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/GD/Simple.pm
line 802, <DATA> line 57.
#unknown color at /mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/GD/Simple.pm
line 802.

This is a bug (or perhaps limitation) in GD​::Simple.

GD​::Simple loads its color table from the DATA file handle, and since handle positions are shared between parents and their forked children the first child manages to successfully load the color table.

When the second child tries however, the position of the DATA handle is already past the end of the color table and so no data is loaded into the %COLORS hash, and the lookup fails.

You can avoid this by calling​:

  GD​::Simple->read_color_table;

before the first fork, or if you prefer not to call an undocumented
function​:

  GD​::Simple->color_names;

which will load the color table so the children don't need to.

Marking this ticket as rejected, this isn't a bug in perl.

Tony

From @karenetheridge

On Wed Jun 03 10​:44​:46 2015, chaoxianli@​micron.com wrote​:

Tony,

Thanks for the quick response and the possible solutions provided.
Just a quick question, why the same code that running on the SUN
Solaris was not affected by the GD​::Simple module?

I have filed this issue in the appropriate rt.cpan.org issue queue here​: https://rt.cpan.org/Ticket/Display.html?id=104947
Future correspondence about the issue should take place in that thread.

From @tonycoz

On Wed Jun 03 10​:44​:46 2015, chaoxianli@​micron.com wrote​:

Tony,

Thanks for the quick response and the possible solutions provided.
Just a quick question, why the same code that running on the SUN
Solaris was not affected by the GD​::Simple module?

Reads from the perl source file are buffered, it's possible there's a
larger buffer on Solaris than on Linux, and that had enough of the color
table in it to resolve the color you were looking up.

Tony