On Fri, 2008-11-28 at 10:09 -0500, Carolyn Beeton wrote: > When I came in this morning I found that supervisor had crashed and > left this output on the console: > > -bash-3.2$ *** glibc detected *** double free or corruption (!prev): > 0x00007f89c000e910 *** > ======= Backtrace: ========= > /lib64/libc.so.6[0x3854872832] > /lib64/libc.so.6(cfree+0x8c)[0x3854875f2c] > /lib64/libcrypto.so.6(CRYPTO_free+0x1d)[0x385f6572fd] > /lib64/libcrypto.so.6(ERR_get_state+0x10b)[0x385f6a093b] > /lib64/libcrypto.so.6(ERR_clear_error+0xd)[0x385f6a0f2d] > /lib64/libssl.so.6(ssl23_connect+0x45)[0x3e7f0220e5] > /home/cbeeton/commit/out/main/lib/libsipXport.so.2(_ZN21OsSSLConnectionSocket13SSLInitSocketEil+0x92)[0x17543a] > > /home/cbeeton/commit/out/main/lib/libsipXport.so.2(_ZN21OsSSLConnectionSocketC1EiPKcl+0xf5)[0x175ef9] > > /home/cbeeton/commit/out/main/lib/libsipXtack.so.2(_ZN11HttpMessage3getER3UrlRS_ib+0x3c1)[0x9a8397] > > /home/cbeeton/commit/out/main/lib/libsipXtack.so.2(_ZN13XmlRpcRequest7executeER14XmlRpcResponse+0x26d)[0xa6f429] > > /home/cbeeton/commit/out/main/lib/libsipXcommserver.so.2(_ZN16AlarmRequestTask13handleMessageER5OsMsg+0x31f)[0x6854c9] > > /home/cbeeton/commit/out/main/lib/libsipXport.so.2(_ZN12OsServerTask3runEPv+0x74)[0x170eca] > > /home/cbeeton/commit/out/main/lib/libsipXport.so.2(_ZN11OsTaskLinux9taskEntryEPv+0x1cd)[0x18f413] > > /lib64/libpthread.so.0[0x3855406407] > /lib64/libc.so.6(clone+0x6d)[0x38548d4b0d] > > Some googling seems to suggest that openssl has a problem in > multi-threaded apps because getpid returns the same value for all > threads. > > The OpenSSL faq says this > (http://www.openssl.org/support/faq.html#PROG1): > > "1. Is OpenSSL thread-safe? > > Yes (with limitations: an SSL connection may not concurrently be used > by multiple threads). On Windows and many Unix systems, OpenSSL > automatically uses the multi-threaded versions of the standard > libraries. If your platform is not one of these, consult the INSTALL > file. > > Multi-threaded applications must provide two callback functions to > OpenSSL by calling CRYPTO_set_locking_callback() and > CRYPTO_set_id_callback(), for all versions of OpenSSL up to and > including 0.9.8[abc...]. As of version 0.9.9, CRYPTO_set_id_callback() > and associated APIs are deprecated by CRYPTO_THREADID_set_callback() > and friends. This is described in the threads(3) manpage. " > > I could not find any evidence in our code base that we do this… have I > missed something?
I don't recall ever seeing that. The natural place for it is probably in sipXportLib/src/os/OsSSL.cpp where the openssl context is established. > Platform is Fedora release 8 (Werewolf) and includes: > -bash-3.2$ rpm -q openssl > openssl-0.9.8b-17.fc8 > > Plug: my supervisorWatcher would have started the supervisor up again! > > Carolyn > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
