问题
When I invoke my multithreaded perl script, on a few occassions, it throws some exception similar to the following. I am sorry that I could not share code. But if really needed I can try to build a snippet (if really really required). Because I guess this should have some theoretical answer.
*** glibc detected *** perl: double free or corruption (!prev): 0x00007f775401e9a0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3d74c75e66]
/lib64/libc.so.6[0x3d74c789b3]
/lib64/libc.so.6[0x3d74c7b880]
/lib64/libc.so.6(realloc+0xe5)[0x3d74c7baf5]
/usr/lib/../lib64/libcrypto.so.10(CRYPTO_realloc+0x5f)[0x7f775907bd8f]
/usr/lib/../lib64/libcrypto.so.10(lh_insert+0xee)[0x7f77590f763e]
/usr/lib/../lib64/libcrypto.so.10(OBJ_NAME_add+0x6b)[0x7f775907f12b]
/usr/lib/../lib64/libcrypto.so.10(EVP_add_cipher+0x27)[0x7f7759102387]
/usr/lib/../lib64/libcrypto.so.10(OpenSSL_add_all_ciphers+0x4b7)[0x7f7759106a07]
/usr/lib/../lib64/libcrypto.so.10(OPENSSL_add_all_algorithms_noconf+0xe)[0x7f775910653e]
/usr/local/lib/libssh2.so.1(libssh2_init+0x39)[0x7f77596800b9]
Why am I getting such errors?
I am using use Thread::Queue; use threads::shared; Please let me know your views.
Below are the thread libraries version info.
use threads; - installed v2.15 (latest - 2.16)
use Thread::Queue; - installed v3.12 (up to date)
use threads::shared; - installed v1.56 (latest - 1.57)
perl - installed v5.26.1
Other libraries are::
use YAML::XS 'LoadFile'; - 0.66 up to date
use Net::Netconf::Manager; - 1.02 up to date
use Config::Properties; - 1.80 up to date
use Sys::Syslog; - 0.35 up to date
use DateTime::Format::Strptime; - 1.74 up to date
use DateTime; - 1.44 up to date
use XML::LibXML; - 2.0129 (latest 2.0139)
use Regexp::Common qw/net/; - 2017060201 up to date
use Getopt::Long; - 2.5 up to date
回答1:
To give you a firm answer, we need something we can run and troubleshoot. Otherwise the error is not reproducible.
Having said that - this looks like something similar to what I have encountered before with certain modules not being thread safe - they'll often run fine, and then very occasionally explode in your face.
E.g. Crypt::SSLeay back in 2008. Net::SSLeay prior to 1.4.2
The general workaround is to stop loading the culprits at compile time with use - because then the same state is inherited by all threads - and instead within the thread, load them at runtime with require and import. By doing this, you're isolating them - your threads will take slightly longer to start, but you shouldn't be spamming threads anyway in perl.
Or use a different module that is thread safe.
With your update and screenshot - Net::SSH2 is mentioned - and that implies one of your other modules is pulling that in.
However Net::SSH thread safey indicates that libssh might have some constraints on thread safety:
Thread-safe: just don't share handles simultaneously
You don't explicitly mention using it, but it looks like it's being pulled in by another module. At a guess, that'll be Net::Netconf::Manager.
And as a second further guess - it might well be doing the 'share handles' because it doesn't realise it's being run in a thread.
So this module is the one I'd suggest isolating within the threads:
require 'Net::NetConf::Manager';
Net::NetConf::Manager -> import;
And do the instantiation within-thread.
As you're using a worker-threads model, this should be minimal overhead, and will mean that you're not hitting this problem.
But more generally - it's unwise to assume modules are thread safe unless they explicitly say they are. The major 'tripping' points are usually whenever any sort of resource sharing can be assumed/implied by the module, such as network sockets, file handles, database connections etc. Often a socket is created at instantiation (e.g. the point where you pass username/password) and having two threads trying to drive a socket concurrently is a potential race condition.
来源：https://stackoverflow.com/questions/47074511/perl-multithreading-script-prints-memory-map-and-backtrace