Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

glibc error in linux

by srinivas_rocks (Sexton)
on Mar 03, 2008 at 09:47 UTC ( #671621=perlquestion: print w/replies, xml ) Need Help??

srinivas_rocks has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks,

Firstly, I thank all the people here for helping/supporting me for all my previous questions, and here is the next. Hope you will give your valuable suggestions even for this.

I am implementing threads and threads::shared modules in order to connect to multiple hosts and execute some operation on the remote systems using the Net::SSH2 module.

The above described application was developed and tested successfully on Solaris 8, 9 platforms. When tested the same on linux platform Redhat ES 3 resulting in the following errors

*** glibc detected *** double free or corruption (!prev): 0x085873e0 ***

By searching over in google and even in perlmonks too ( -- there was no reply for this ). We could guess that there might be some problem with the linux version or glibc or perl.

We have used another version of linux i.e Redhat ES 4, but did not fetch us anything. Same error arised. Then we have upgraded the glibc 2.3.4-2 to glibc 2.7 which due to some inconsistency or improper library linking resulted in unusable system.

We are using Active State perl and even upgarded that from 5.8.8 and even tested the same thing on Fedora Core 4 systems. But no luck.

Please let us know if we have any work around or any help to overcome that problem.

Thanks in advance.


Replies are listed 'Best First'.
Re: glibc error in linux
by shmem (Chancellor) on Mar 03, 2008 at 10:09 UTC
    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.


    _($_=" "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}
      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.
Re: glibc error in linux
by tirwhan (Abbot) on Mar 03, 2008 at 11:08 UTC

    I agree with shmem, try using the perl version the system shipped with. Also, check whether the version of libssh2 you have installed matches what your version of Net::SSH2 supports (read the Net::SSH2 changelog for that). I'd also say there's a good chance that Net::SSH2 is not thread-safe, try your script without using threads and see if you get the same error.

    All dogma is stupid.
Re: glibc error in linux
by zentara (Archbishop) on Mar 03, 2008 at 13:22 UTC
    I agree with tirwhan. I've seen that error quite often when doing initial prototypes of scripts using threads. You have to remember, that when you create a thread, it gets a complete copy of the parent, at the time of it's birth. So if you have a script that loads alot of modules, and creates a bunch of objects, THEN creates the threads, when the thread runs, there will be confusion between the parent's object, and the thread's copy. That's where the "double free" comes from, I believe, when the script tries to clean up an object when the thread exits, but a second copy exists. See threads: spawn early to avoid the crush. and Use thread with good care, but definitely keep using it

    The Glib module tries to keep track of extra objects, to improve thread safety, with

    #this line causes the warning, but dosn't die die "Glib::Object thread safetly failed" unless Glib::Object->set_threadsafe (TRUE);
    so you may want to look into GLib, (which is the base object class for Gtk2, and works without X ).

    The other thing to do, is try to keep your objects in the thread code block, don't create objects in the parent thread before the threads are created.

    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
Re: glibc error in linux
by stiller (Friar) on Mar 03, 2008 at 10:07 UTC
    Ouch, I'm really not good at resolving that kind of things, but you seem to hav mangled the glibc installation, and just blindly upgrading to the latest version is not usually a good idea. Use your package manager, and try to establish what version of glibc other software installed relies on, get that version back.

    Good luck

Re: glibc error in linux
by welchavw (Pilgrim) on Mar 04, 2008 at 02:05 UTC

    I couldn't help this post. I love Perl beyond words. That said, personally I stay away from using threads with Perl. I have always thought that there were too many caveats and the consequences of failure too severe. For me, fork and exec have always gained me the kinds of control and concurrency that I have looked for when scripting. This is no doubt heretical to some/many but that's how I use the language and I won't be changing. I am just too damn productive when I am not worrying if every level underneath me is thread-safe. I understand, BTW, that there are some other CPAN approaches beyond fork and exec and I have read very nice things about them; I have merely never had cause to investigate.

Re: glibc error in linux
by djp (Hermit) on Mar 04, 2008 at 02:29 UTC
    On RHEL AS4, 'man -s 3 malloc' states:
    Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) include a malloc implementation which is tunable via environment variables. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, and memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is called immediately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.
    You can use MALLOC_CHECK_ to detect or ignore your duplicate free error message. Note that the above doco is inaccurate, see (glibc) for an accurate description. Hope this helps.
Re: glibc error in linux
by chromatic (Archbishop) on Mar 04, 2008 at 01:11 UTC

    zentara is right. This is not a problem in glibc. This is glibc's memory management functions (the system malloc and free) telling you that there is a problem in something which uses glibc.

Re: glibc error in linux
by Anonymous Monk on Mar 11, 2008 at 19:00 UTC
    I'm just passing through but have experienced problems with threads in redhat. We have the same glibc version as you and our test binary occasionally crashes. Which is how I found this thread.

    Our program works when we replace the allocator, it also works with another system here that has a later version of glibc (glibc-2.3.4-2.19).

    You might want to try, like we did replacing your allocator. To see if you get an improvement. See Google Thread Allocator You need not play around with your libc install to do this.

    Andy Gavin

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://671621]
Approved by Corion
Front-paged by Corion
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (7)
As of 2023-12-11 08:37 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (41 votes). Check out past polls.