Re: OpenSSL 1.0.1c deadlock
We've managed on a few occasions now to reproduce an issue where OpenSSL deadlocks while trying to acquire a mutex it already has. I filed http://rt.openssl.org/Ticket/**Display.html?id=2866http://rt.openssl.org/Ticket/Display.html?id=2866 about this issue. I currently have a server where this has occurred, with the process in GDB. However, the team that owns the server needs it back, so I wanted to know if there is anything further the dev team would like me to gather from the process before I drop out of GDB. So far we've encountered this issue on both SLES11 SP2 and Ubuntu 12 LTS linux distributions. Thanks -- I've managed to find the buggy code (crypto/asn1/x_pubkey.c calls EVP_PKEY_free(ret) while holding lock CRYPTO_LOCK_EVP_PKEY, but EVP_PKEY_free(ret) always tries to obtain that lock first). Will patch this in a moment. Bodo
Re: OpenSSL 1.0.1c deadlock
--On Wednesday, September 05, 2012 3:14 PM -0400 Bodo Moeller bmoel...@acm.org wrote: On Wed, Sep 5, 2012 at 3:06 PM, Bodo Moeller bmoel...@acm.org wrote: We've managed on a few occasions now to reproduce an issue where OpenSSL deadlocks while trying to acquire a mutex it already has. I filed http://rt.openssl.org/Ticket/Display.html?id=2866 about this issue. I currently have a server where this has occurred, with the process in GDB. However, the team that owns the server needs it back, so I wanted to know if there is anything further the dev team would like me to gather from the process before I drop out of GDB. So far we've encountered this issue on both SLES11 SP2 and Ubuntu 12 LTS linux distributions. Thanks -- I've managed to find the buggy code (crypto/asn1/x_pubkey.c calls EVP_PKEY_free(ret) while holding lock CRYPTO_LOCK_EVP_PKEY, but EVP_PKEY_free(ret) always tries to obtain that lock first). Will patch this in a moment. Actually I see this has been fixed already -- please try the latest 1.0.0 snapshot to confirm: http://cvs.openssl.org/chngview?cn=22572 Yes, I've rebuilt with this patch in place. ;) However, it was extremely difficult to trigger (2 times in 4 weeks of heavy testing), so it is difficult for me to prove conclusively if this fixes it or not, although I agree the code inspection implies it is fixed. ;) --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.1c deadlock
On Wed, Sep 5, 2012 at 3:06 PM, Bodo Moeller bmoel...@acm.org wrote: We've managed on a few occasions now to reproduce an issue where OpenSSL deadlocks while trying to acquire a mutex it already has. I filed http://rt.openssl.org/Ticket/**Display.html?id=2866http://rt.openssl.org/Ticket/Display.html?id=2866 about this issue. I currently have a server where this has occurred, with the process in GDB. However, the team that owns the server needs it back, so I wanted to know if there is anything further the dev team would like me to gather from the process before I drop out of GDB. So far we've encountered this issue on both SLES11 SP2 and Ubuntu 12 LTS linux distributions. Thanks -- I've managed to find the buggy code (crypto/asn1/x_pubkey.c calls EVP_PKEY_free(ret) while holding lock CRYPTO_LOCK_EVP_PKEY, but EVP_PKEY_free(ret) always tries to obtain that lock first). Will patch this in a moment. Actually I see this has been fixed already -- please try the latest 1.0.0 snapshot to confirm: http://cvs.openssl.org/chngview?cn=22572
