Bug 90422 - (IT_64547) Perl dies with "panic: end_shift" errors
Perl dies with "panic: end_shift" errors
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: perl (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Warren Togami
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-05-07 19:32 EDT by Steevithak
Modified: 2007-11-30 17:06 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-28 03:14:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steevithak 2003-05-07 19:32:21 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
Many perl scripts which run fine on RedHat 6.2, 7.3, and 8.0 are dying with the
error, panic: end_shift on lines of code that use regular expression. I believe
(but am not certain) this may be caused by the RedHat Perl binary missing patch


This patch fixes a bug which caused end_shift panic on regular expressions -
however, it seems to refer to UTF-8 code and we processing only plain ASCII text
files so I don't know if this would affect us or not.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. I'm working on a simplified test case and will attach it later

Actual Results:  Perl dies with a panic: end_shift error

Expected Results:  Perl execute code correctly

Additional info:
Comment 1 Steevithak 2003-05-09 18:03:45 EDT
Found a workaround and won't have time to work on a test case for a while. But
it does appear to be a bug in RedHat's build of Perl related to regular
expressions and UTF-8. I'm not actually processing UTF-8 data in the first place
but for some reason this build of Perl thinks everything is UTF-8. Anyway, I
discovered that putting a "use bytes;" pragma at the begining of the code seem
to turn off the defective UTF-8 stuff.
Comment 2 Richard Duran 2004-08-18 14:04:04 EDT
Thanks for the workaround! This issue still exists in perl-5.8.0-88.4
on AS3.0. Here is a test case:

--------------------- begin ----------------
#!/usr/bin/perl -w
use File::Basename;
while (<STDIN>) {
   $bname = basename ($_);
   ($dname = $_) =~ s/\/$bname$//;
   print "d=$dname b=$bname\n";
------------------ end ----------------

This panics on input like "/asdffa/asfddsa/asfas.xx" and misbehaves on
input like "/asdfsa/asdfsf/sdfas".

Comment 3 Richard Duran 2004-08-18 14:53:24 EDT
removing the end-of-string "$" from s/// avoids the panic, but is not
the desired behavior.

Comment 4 Nick (Gunnar) Bluth 2004-09-28 11:09:30 EDT
It's oviously related to UTF-8:

(/tmp/test.pl is the above script)

$ /tmp/test.pl
panic: end_shift at /tmp/test.pl line 6, <STDIN> line 1.
$ LANG=en_US /tmp/test.pl
d=/asdffa/asfddsa b=asfas.xx

So, (un-)setting LANG is a clean workaround to this?


Comment 6 David Steiner 2005-02-24 09:55:13 EST
We are still seeing this bug in perl-5.8.0-89.10 on RHEL 3WS. The failure mode is the 
same for the test program in Comment #2 and using the "use:bytes" pragma is still a 
workaround. However, this is not being caused by the perl bug noted in the initial 
description. That patch was applied by perl-5.8.0-upstream-18197.patch.

Comment 7 David Steiner 2005-02-24 10:13:58 EST
I forgot to include this in the last comment:

We compiled perl 5.8.6 from perl.org on our target machine and it does not exhibit this 
behavior. Apparently, we are still missing a key patch.

Comment 8 Bastien Nocera 2005-02-24 10:21:24 EST
I'll update this with some words from the maintainer:
utf8 issues in perl 5.8.0 are difficult to resolve without ending up
breaking ABI.  we've applied a number of patches to help and will
investigate other options, but it is unlikely further changes can be
made without significantly more divergence from upstream.

So, it is known that it is still a problem, and we would advise you to
either "not do that", or use the Perl as shipped with RHEL4, as it
doesn't exhibit those problems.
Comment 12 Warren Togami 2005-05-28 03:14:29 EDT
Agreement from engineering is that this is infeasible to fix.  Sorry.  Your
options are to upgrade perl yourself or use RHEL4.

Note You need to log in before you can comment on or make changes to this bug.