Bug 90422 (IT_64547) - Perl dies with "panic: end_shift" errors
Summary: Perl dies with "panic: end_shift" errors
Keywords:
Status: CLOSED WONTFIX
Alias: IT_64547
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: perl
Version: 3.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Warren Togami
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-05-07 23:32 UTC by Steevithak
Modified: 2007-11-30 22:06 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-28 07:14:29 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Steevithak 2003-05-07 23:32:21 UTC
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
18178:

  http://archive.develooper.com/perl5-changes@perl.org/msg06202.html

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):
perl-5.8.0-88

How reproducible:
Always

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

Actual Results:  Perl dies with a panic: end_shift error

Expected Results:  Perl execute code correctly

Additional info:

Comment 1 Steevithak 2003-05-09 22:03:45 UTC
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 18:04:04 UTC
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>) {
   chop;
   $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".

-richard

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

-richard

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

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

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

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

Cheers,

Nick

Comment 6 David Steiner 2005-02-24 14:55:13 UTC
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.

Thanks,
-David-

Comment 7 David Steiner 2005-02-24 15:13:58 UTC
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.

-David-

Comment 8 Bastien Nocera 2005-02-24 15:21:24 UTC
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 07:14:29 UTC
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.