Bitten By the Red Hat Perl Bug

snydeq writes "Smart coders always optimize the slowest thing. But what if 'the slowest thing' is the code supplied by your vendor? That was exactly the situation Vipul Ved Prakash discovered when he tinkered with a company Linux box on which Perl code was running at least 100 times slower than expected. The code, he found, was running on CentOS Linux, using Perl packages built by Red Hat. So Prakash got rid of the Perl executable that came with CentOS, compiled a new one from stock, and the bug disappeared. 'What's more disturbing,' McAllister writes, 'is that this Red Hat Perl performance issue is a known bug,' first documented in 2006 on Red Hat's own Bugzilla database. Folks affected by the current bug have two options: sit tight, or compile the Perl interpreter from source — effectively waiving your support contract. If a Linux vendor can't provide comprehensive maintenance and support for the open source software projects you depend on, McAllister asks, who ever will?"

Comments

waiving your support contract?

[dougmc]

Installing your own perl under /usr/local, leaving the system one alone under /usr, that waives your support contract?

Seems unlikely, and if actually true, remarkably stupid.

(However, messing with the perl under /usr, that would be a mistake. It could easily break other things that depended on that specific version ...)

Re:waiving your support contract?

[Richard_at_work]

No, it doesn't waive your support contract, but it does mean you will be relying on a subsystem that is not supported by the vendor - which validates the 'effectively' modifier in the original statement.

Re:waiving your support contract?

[no1home]

Very true. And this has been an ongoing issue with Linux adoption... I have a friend who runs mega-million-dollar, mission-critical systems and they've had to move off of Linux in favor of (Sun? Don't remember right now). It isn't about functionality. It isn't about open source. It's about support. Red Hat, et. al. want to be enterprise systems, and claim to offer enterprise support. But they don't perform enterprise support. As indicated here, change something to fix a bug, and you don't get support for that piece anymore. More, they won't support a system that doesn't have the latest updates, which is a problem on mission-critical systems. We don't update needlessly, and we certainly don't update to 'today's' patch. We have to wait and be sure the patch is stable and provides an improvement without risking our mission.

Until the players selling support realize all of this, Linux will be a difficult sell for such key systems (and the PHBs all think ALL their systems are mission-critical).

Keep in mind, I say this lovingly.... I want Linux to succeed and prefer it over the popular alternative.

Re:waiving your support contract?

[/ASCII]

The company I work for does support for any Linux distribution, custom compiled packages, whatever. If the customer uses non-standard packages and oddball solutions, it often takes more time to solve their problems, but since we work by the hours, that's their problem.

I find it hard to believe that businesses such as ours are unusual.

Re:waiving your support contract?

[KaZen]

This is nearly opposite my experience. I'm working at a very large Wall Street firm.

Red Hat does *not* tell us: "Oh, I'm sorry you're not running the latest support pack, no support for you."

We've had to run a modified GCC for a while and Red Hat, *again* didn't say "You've changed it, so support for you." What they *did* say was, "Can you reproduce this on *our* gcc?" Which again is better than We've gotten from some other vendors.

We're still running AS4U4 in some places and RH has worked with us to track down bugs. Sometimes it ends with: "This was fixed in 4.5 please update." Sometimes it ends with "This is a bug, and here is the HF, please update to the released version when it becomes available."

In fact I have a hard time sometimes of getting our Admins to open tickes with the *right* vendor, because they'd rather open a ticket with RH, because it gets solved sooner. (Course that is more a dig on HP, Veritas, EMC and some other "Enterprise Software" companies.)

Unfortunately for Both us and RH, we don't like to update either, and even when RH has proven an update solves the problem, it's hard to get the Admins to actually update the boxen.

CentOS it NOT Red Hat

[Anonymous Coward]

If it is "supplied by CentOS" then it was compiled by "CentOS" not Red Hat. Red Hat Enterprise Linux enterprise had a hotfix for this weeks ago. So if Vipul had been using a Red Hat product, he would not have had this problem.

Re:CentOS it NOT Red Hat

[Anonymous Coward]

And recompiling doesn't invalidate his support contract; as a CentOS user he doesn't have one.

The summary is bullshit.

Re:Article is a troll

[A beautiful mind]

Still think it's a troll?

This is what a perl core hacker has to say about the issue:

It seems that there is still a problem with RedHat's packaged perl 5.8."8"**. RedHat seem to have an aggressive policy of incorporating pre-release changes in their released production code. This would not be so bad if they actually communicated back with upstream (i.e. me and the other people on the perl5-porters mailing list), or demonstrated that they had sufficient in-house knowledge that they didn't need to. But evidence suggests that neither is true, certainly for 5.8.x

Let me stress that there has never been this problem in any released Perl, 5.8.7, 5.8.8, 5.10.0, and it won't be in 5.8.9 either when it comes out. The problem was caused by changes I made in the 5.8.x tree that RedHat integrated. End users reported the first bug something like 2 years ago, and RedHat closed it as "upstream patch" rather than reporting back "you know that pre-release change you made, that we integrated - well, it seems to have some problems"

(...)

For their versions affected, RedHat merely need to put out a patch integrating changes 31996, 32018, 32019 and 32025 which FIX IT, are documented as FIXING IT, and are from NOVEMBER 2007.

Re:Don't throw out the baby with the bath water

[canUbeleiveIT]

Just because Red Hat made one high-profile mistake, doesn't mean their support service is without value.

Perhaps not, but I know that they will never get another dime of my money.

For years, I always purchased Red Hat even though I never had occasion to use the support that came with it. I was (and still am) bought into the FOSS concept and wanted to make it work for me and my business. But I stopped sending RH my money sometime about 8.0, when I called their support to try and get some help with a printer issue. I would have been satisfied if they had been able to get either one of my printers (HP LaserJet 1100 or LaserJet 4L) to work with RH. A surly woman with almost unrecognizable English--obviously reading off of a cue card--tried for a few minutes and then dismissed my support case with the comment that "RedHat doesn't work with all printers." When I mentioned that I had paid for the RedHat just so that I could have support, she hung up on me. I called back to get another support person with an equally incompetent and rude tech.

Eventually, someone at experts-exchange.com gave me the answer to my problem. Now I just download Centos and if I need support, I pay someone on a case-by-case basis.

Re:That's what you get.

[chromatic]

Fast and correct always wins, and the real Perl hackers are working on that.

No released version of Perl ever had this bug. Red Hat pulled a patch from a development version of Perl and maintained it over released versions of Perl which did not need it. That's the source of this bug. The Perl developers fixed this bug before releasing the next stable version of Perl.