RE: double free or corruption
From: Kyle Sent: Wednesday, April 06, 2011 10:12 AM Hi, when trying to compile openssl 1.0.0d with this configure: ./Configure mingw64 no-shared --openssldir=/home/kyle/software/ffmpeg/external-libraries/win64 and then this make: make CC=x86_64-w64-mingw32-gcc RANLIB=x86_64-w64-mingw32-ranlib I get this error: ... *** glibc detected *** /home/kyle/software/mingw-w64/mingw-w64-x86_64/lib/gcc/x86_64- w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/bin/ld: double free or corruption (!prev): 0x02a8aaa0 *** === Backtrace: = /lib/libc.so.6(+0x774b6)[0x2b65b045a4b6] /lib/libc.so.6(cfree+0x73)[0x2b65b0460c83] /home/kyle/software/mingw-w64/mingw-w64-x86_64/lib/gcc/x86_64- w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/bin/ld[0x4592bc] ... Does anyone have any ideas about this? The program 'ld', which judging from the path is part of mingw, has a bug. I managed to build the same openssl version before, using the same command line, and the same version of binutils. The only thing that has changed is my gcc version, I'm not using 4.6.0 and updated my mingw-w64 toolchain. Then I'd either get the bug fixed or revert to a version of mingw which works.__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: double free or corruption (!prev) in CRYPTO_free()? ---Fix done in OpenSSL
Hi, It was seen that the CRYPTO_thread_id() uses getpid() which was returning same value for all threads. Instead of getpid() I used pthread_self() which appears to have solved the problem that I had reported in this mail. I am not seeing the problem re-occur. Another users post referrring to the same case can be found at http://www.mail-archive.com/[EMAIL PROTECTED]/msg21031.html. I use the linux kernel 2.6 Is using pthread_self() OK. Or is there any better way which would yeild correct thread IDs in CRYPTO_thread_id()? Regards, Prabhu. S On 8/1/07, Prabhu S [EMAIL PROTECTED] wrote: I shall use the tool to get more insights. In line with the issue reported(application crash if too many simultaneous SSL handshake occurs) , I am seeing application crash under stress performance(with valid SSL sessions). The stack trace is quite identical to posted earlier: #0 0x4402 in __kernel_vsyscall () #1 0x001fc1f8 in raise () from /lib/libc.so.6 #2 0x001fd948 in abort () from /lib/libc.so.6 #3 0x0023152a in __libc_message () from /lib/libc.so.6 #4 0x00237424 in _int_free () from /lib/libc.so.6 #5 0x0023795f in free () from /lib/libc.so.6 #6 0x4057d602 in CRYPTO_free (str=0x9dc98360) at mem.c:378 #7 0x405e84f5 in ERR_clear_error () at err.c:722 #8 0x403999ad in ssl3_connect (s=0xa0d6aa58) at s3_clnt.c:169 #9 0x403b06ac in SSL_connect (s=0xa0d6aa58) at ssl_lib.c:850 About 600 threads keep connecting to server in a cyclic manner. Thanks, Prabhu. S On 7/27/07, Darryl Miles [EMAIL PROTECTED] wrote: Prabhu S wrote: Hi David, I enabled the debug flags in the OpenSSL makefiles and recompiled for the libraries. The stack trace is obtained is as follows: #0 0x4402 in __kernel_vsyscall () #1 0x001fc1f8 in raise () from /lib/libc.so.6 #2 0x001fd948 in abort () from /lib/libc.so.6 #3 0x0023152a in __libc_message () from /lib/libc.so.6 #4 0x00237424 in _int_free () from /lib/libc.so.6 #5 0x0023795f in free () from /lib/libc.so.6 #6 0x4057b602 in CRYPTO_free (str=0x640f9c38) at mem.c:378 #7 0x405e64f5 in ERR_clear_error () at err.c:722 #8 0x403999ad in ssl3_connect (s=0x63e384c8) at s3_clnt.c:169 #9 0x403b06ac in SSL_connect (s=0x63e384c8) at ssl_lib.c:850 Does it indicate a OpenSSL problem?..I have dug the application code and so far appears it appears to be clean. It only indicate that OpenSSL was the user freeing the memory at the time glibc detected a problem. Glibc's detection of these problems is not fool proof, maybe you should look at valgrind (but dont forget to compile OpenSSL with -DPURIFY) before using the package. Darryl __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: double free or corruption (!prev) in CRYPTO_free()? ---Fix done in OpenSSL
Hello, It was seen that the CRYPTO_thread_id() uses getpid() which was returning same value for all threads. Instead of getpid() I used pthread_self() which appears to have solved the problem that I had reported in this mail. I am not seeing the problem re-occur. Another users post referrring to the same case can be found at http://www.mail-archive.com/[EMAIL PROTECTED]/msg21031.html. I use the linux kernel 2.6 Is using pthread_self() OK. Or is there any better way which would yeild correct thread IDs in CRYPTO_thread_id()? CRYPTO_thread_id uses getpid() if no other ID functions was set. Some example of initializing crypto locking you may find at: http://www.nabble.com/When-to-use-CRYPTO_set_locking_callback%28%29-and-CRYPTO_set_id_callback%28%29--tf2121027.html#a6333104 In this example locking callback function is defined (using pthread_self()) and set at startup. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: double free or corruption (!prev) in CRYPTO_free()?
I shall use the tool to get more insights. In line with the issue reported(application crash if too many simultaneous SSL handshake occurs) , I am seeing application crash under stress performance(with valid SSL sessions). The stack trace is quite identical to posted earlier: #0 0x4402 in __kernel_vsyscall () #1 0x001fc1f8 in raise () from /lib/libc.so.6 #2 0x001fd948 in abort () from /lib/libc.so.6 #3 0x0023152a in __libc_message () from /lib/libc.so.6 #4 0x00237424 in _int_free () from /lib/libc.so.6 #5 0x0023795f in free () from /lib/libc.so.6 #6 0x4057d602 in CRYPTO_free (str=0x9dc98360) at mem.c:378 #7 0x405e84f5 in ERR_clear_error () at err.c:722 #8 0x403999ad in ssl3_connect (s=0xa0d6aa58) at s3_clnt.c:169 #9 0x403b06ac in SSL_connect (s=0xa0d6aa58) at ssl_lib.c:850 About 600 threads keep connecting to server in a cyclic manner. Thanks, Prabhu. S On 7/27/07, Darryl Miles [EMAIL PROTECTED] wrote: Prabhu S wrote: Hi David, I enabled the debug flags in the OpenSSL makefiles and recompiled for the libraries. The stack trace is obtained is as follows: #0 0x4402 in __kernel_vsyscall () #1 0x001fc1f8 in raise () from /lib/libc.so.6 #2 0x001fd948 in abort () from /lib/libc.so.6 #3 0x0023152a in __libc_message () from /lib/libc.so.6 #4 0x00237424 in _int_free () from /lib/libc.so.6 #5 0x0023795f in free () from /lib/libc.so.6 #6 0x4057b602 in CRYPTO_free (str=0x640f9c38) at mem.c:378 #7 0x405e64f5 in ERR_clear_error () at err.c:722 #8 0x403999ad in ssl3_connect (s=0x63e384c8) at s3_clnt.c:169 #9 0x403b06ac in SSL_connect (s=0x63e384c8) at ssl_lib.c:850 Does it indicate a OpenSSL problem?..I have dug the application code and so far appears it appears to be clean. It only indicate that OpenSSL was the user freeing the memory at the time glibc detected a problem. Glibc's detection of these problems is not fool proof, maybe you should look at valgrind (but dont forget to compile OpenSSL with -DPURIFY) before using the package. Darryl __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: double free or corruption (!prev) in CRYPTO_free()?
Hi David, I enabled the debug flags in the OpenSSL makefiles and recompiled for the libraries. The stack trace is obtained is as follows: #0 0x4402 in __kernel_vsyscall () #1 0x001fc1f8 in raise () from /lib/libc.so.6 #2 0x001fd948 in abort () from /lib/libc.so.6 #3 0x0023152a in __libc_message () from /lib/libc.so.6 #4 0x00237424 in _int_free () from /lib/libc.so.6 #5 0x0023795f in free () from /lib/libc.so.6 #6 0x4057b602 in CRYPTO_free (str=0x640f9c38) at mem.c:378 #7 0x405e64f5 in ERR_clear_error () at err.c:722 #8 0x403999ad in ssl3_connect (s=0x63e384c8) at s3_clnt.c:169 #9 0x403b06ac in SSL_connect (s=0x63e384c8) at ssl_lib.c:850 Does it indicate a OpenSSL problem?..I have dug the application code and so far appears it appears to be clean. Thanks, Prabhu. S On 7/25/07, Dr. Stephen Henson [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007, Prabhu S wrote: Hi, I have a SSL enabled client application. The client connects to the server with which it shares no common ciphers. When 200 or more simultaneous connections are made the application crashes. The backtrace indicates double free or corruption (!prev) in CRYPTO_free(). However when there is a common shared ciphers between the client and server there are no issues. #0 0x4402 in __kernel_vsyscall () #1 0x001fc1f8 in raise () from /lib/libc.so.6 #2 0x001fd948 in abort () from /lib/libc.so.6 #3 0x0023152a in __libc_message () from /lib/libc.so.6 #4 0x00237424 in _int_free () from /lib/libc.so.6 #5 0x0023795f in free () from /lib/libc.so.6 #6 0x4056e6fa in CRYPTO_free () from ../lib/libcrypto.so.0.9.8 The client uses libcrypto.so.0.9.8. Is there any known issues in libcrypto.so.0.9.8?.. Whats baffling me is there are no issues in successful handshakes but application quite immediately crashes with failed handshakes. The way the client handles cleanup is same for both the cases. Simultaneous connections are achieved by creating threads , one thread for every connections. But the CTX and SSL objects are all different for each threads. That isn't necessarily a problem with OpenSSL. Application error could have a similar effect. Does the stack trace go any further than that? Debugging symbols would help then we'd know which function had called CRYPTO_free() though it might be the first one that is the culprit. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: double free or corruption (!prev) in CRYPTO_free()?
On Thu, Jul 26, 2007, Prabhu S wrote: Hi David, I enabled the debug flags in the OpenSSL makefiles and recompiled for the libraries. The stack trace is obtained is as follows: #0 0x4402 in __kernel_vsyscall () #1 0x001fc1f8 in raise () from /lib/libc.so.6 #2 0x001fd948 in abort () from /lib/libc.so.6 #3 0x0023152a in __libc_message () from /lib/libc.so.6 #4 0x00237424 in _int_free () from /lib/libc.so.6 #5 0x0023795f in free () from /lib/libc.so.6 #6 0x4057b602 in CRYPTO_free (str=0x640f9c38) at mem.c:378 #7 0x405e64f5 in ERR_clear_error () at err.c:722 #8 0x403999ad in ssl3_connect (s=0x63e384c8) at s3_clnt.c:169 #9 0x403b06ac in SSL_connect (s=0x63e384c8) at ssl_lib.c:850 Does it indicate a OpenSSL problem?..I have dug the application code and so far appears it appears to be clean. It isn't immediately clear if that is an OpenSSL problem or not. The error code makes extensive use of locks and thread IDs. If there is a problem with either the locking callbacks or the thread ID callback then that could cause this problem. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: double free or corruption (!prev) in CRYPTO_free()?
On Wed, Jul 25, 2007, Prabhu S wrote: Hi, I have a SSL enabled client application. The client connects to the server with which it shares no common ciphers. When 200 or more simultaneous connections are made the application crashes. The backtrace indicates double free or corruption (!prev) in CRYPTO_free(). However when there is a common shared ciphers between the client and server there are no issues. #0 0x4402 in __kernel_vsyscall () #1 0x001fc1f8 in raise () from /lib/libc.so.6 #2 0x001fd948 in abort () from /lib/libc.so.6 #3 0x0023152a in __libc_message () from /lib/libc.so.6 #4 0x00237424 in _int_free () from /lib/libc.so.6 #5 0x0023795f in free () from /lib/libc.so.6 #6 0x4056e6fa in CRYPTO_free () from ../lib/libcrypto.so.0.9.8 The client uses libcrypto.so.0.9.8. Is there any known issues in libcrypto.so.0.9.8?.. Whats baffling me is there are no issues in successful handshakes but application quite immediately crashes with failed handshakes. The way the client handles cleanup is same for both the cases. Simultaneous connections are achieved by creating threads , one thread for every connections. But the CTX and SSL objects are all different for each threads. That isn't necessarily a problem with OpenSSL. Application error could have a similar effect. Does the stack trace go any further than that? Debugging symbols would help then we'd know which function had called CRYPTO_free() though it might be the first one that is the culprit. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
