On Sun Sep 23 05:57:38 2007, philip@gladstonefamily.net wrote: > After realizing that the current code doesn't correspond with the built > code, I just pulled the redhat RPM, and there was the culprit. > > There was a diff that adds the function S_reset_amagic that is called in > exactly the right place. I attach the culprit patch to show what (I > think) is causing the problem. It is certainly where all the CPU time is > being spent. The original patch posting was in > http://www.nntp.perl.org/group/perl.perl5.changes/2006/03/msg15320.html > > This also suggests that the problem is not limited to 64-bit either! > > Maybe someone more knowledgeable on perl internals can figure out why it > has such pathological behavior in this case. > > Thanks > > Philip > > On Fri Sep 21 19:54:48 2007, philip@gladstonefamily.net wrote: > > Since this doesn't correspond to the current source code, and, when I > > build the current source code, I don't experience the problem, I am at > > a loss as to how to continue. It makes me a little nervous that there > > are multiple versions of 5.8.8 around which behave so differently. > > > > Philip (more puzzled in Massachusetts) > > > > > > As you suspected, this problem was caused by RedHat shipping a Perl with patches pulled in from the development version of Perl. There is a reason why this was not yet in a production version. Anyways, the fully fixed version was included in Perl 5.10.0 and in Perl 5.8.9-RC1. The best solution currently on RedHat is to compile a Perl from source and use that instead. Additional discussion of the problem is available at http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/ Steve Peters