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.

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.

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);
[download]

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.

Good luck

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.

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.

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