in reply to glibc error in linux

We are using Active State perl

Is there a reason for not using the stock perl shipped with RHEL3 (5.8.0-89.10 per update 5) ?

glibc detected doesn't instantly mean it is a glibc error. To detect the source of the problem - does that failure produce a core dump? If so, I'd examine that core file with gdb, maybe that gives some hints. If the perl binary doesn't contain debugging symbols, I'd grab the source rpm, edit the spec file for to use the -g compiler flag, rebuild the rpm, install it and produce a core file with that version.

Running the version with debugging flags in gdb could give some clue too; it is helpful to have the perl source tree still around, to pass the location to gdb with the 'dir' command.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Replies are listed 'Best First'.
Re^2: glibc error in linux
by Hercynium (Hermit) on Mar 04, 2008 at 00:10 UTC
    I can vouch for the stock perl in RHEL3 being quite broken for things that use threads. Also, RedHat seems to have fiddled with perl's CPAN build tool-kit. Modules that I've never seen fail tests fail spectacularly. Using CPAN to update core modules leads to further hell when up2date clobbers part of the updates when updating perl!

    While I've found ways of making all this work, I wouldn't recommend it to any *sane* individual.

    My advice to srinivas_rocks is to try to confirm or rule out ActiveState Perl as your problem as soon as possible, because using it as your system perl on RHEL 3 is *much* better than using RedHat's.

    This isn't to say I'm the be-all end-all authority on this, but I consider myself quite a competent and capable sysadmin and never have I been so dismayed with a core system package as I have been with perl on RedHat Enterprise Linux.