Checking for memory leaks
When compiling with Visual C++, I usually put the following lines somewhere in my debug code: #ifdef _DEBUG _CrtSetDbgFlag(_CRTDBG_CHECK_ALWAYS_DF || _CRTDBG_DELAY_FREE_MEM_DF || _CRTDBG_LEAK_CHECK_DF); #endif and #ifdef _DEBUG IMAssert(_CrtCheckMemory()); IMAssert(!_CrtDumpMemoryLeaks()); #endif With OpenSSL 0.9.4, Visual C++ reports memory leaks even if I only use these two lines of OpenSSL code: SSL_CTX *ctx = SSL_CTX_new(SSLv2_server_method()); SSL_CTX_free(ctx); Question is: do I have to free anything else manually or is the leak caused by a OpenSSL "bug". Thanks, Remo ___ [ [EMAIL PROTECTED] ] "Ich dusche warm!" [ http://public.toilet.ch/ ] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
socket I/O and EOF
There appears to be a problem with OpenSSL when used with non-blocking I/O on Linux. (Running SuSE 6.0, Linux kernel 2.2.5.) A similar situation seems to be happening on NT as well. The code doesn't seem to detect that a socket has been closed by the remote end. Read loops tend to execute a huge number of times in this case, always returning 0 bytes of data. I haven't figured out how/why the loop ever terminates, but in normal situations, it eventually does. In one case in particular in the OpenLDAP slapd (developer snapshot) if a session is just being started, and SSL_accept fails, slapd will loop forever, retrying the SSL_accept. (This assumes the slapd is configured to require a user certificate. The error can be reproduced by using a client without a user certificate to connect to the slapd.) In slapd the I/O loop is structured around a select(). As you know, select will return "readable" for a socket that was closed, and a read on this socket will return 0 bytes to indicate EOF. Unfortunately, it appears that the SSL library doesn't do anything special when a read returns 0 bytes. In particular, the SSL session handle's rwstate variable remains set to SSL_READING in this case, and the upper levels treat this as "a read was incomplete and should be retried." Of course, none of the retries will ever succeed, and so you have a fine infinite loop. This message is going to both the OpenSSL and the OpenLDAP crew because I haven't figured out yet who's doing the wrong thing. This infinite loop may be caused by the ldap_pvt_tls_accept that we wrap around SSL_accept. The large number of loops even in the successful case seems to be a more general problem. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
socket I/O, EOF, openssl 0.9.4
Following up on my previous email... This patch to ssl23_read_bytes() seems to fix my problem with bogus clients hosing SSL_accept(): --- s23_pkt.c 1999/12/08 17:20:56 1.1.1.1 +++ s23_pkt.c 2000/01/14 19:58:16 @@ -104,9 +104,9 @@ s-rwstate=SSL_READING; j=BIO_read(s-rbio,(char *)(p[s-packet_length]), n-s-packet_length); + s-rwstate=SSL_NOTHING; if (j = 0) return(j); - s-rwstate=SSL_NOTHING; s-packet_length+=j; if (s-packet_length = (unsigned int)n) return(s-packet_length); It strikes me that if BIO_read returns =0, something irrecoverably bad has happened, and there's no point in coming back to try again later. Currently the code in slapd that invokes SSL_accept has a test if (!SSL_want_nothing(ssl)) to decide if the accept should be retried. This works in the normal case, when all the data for the transaction arrives in multiple chunks and can't be read all at once. But without the above patch, it causes the accept to be retried forever on a bogus connection. Perhaps this is the wrong approach, but there doesn't seem to be any obvious way to distinguish "we're OK, just in the middle of a long transaction" from "we're hosed, this connection is invalid" in the SSL_accept return status. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: socket I/O and EOF
More than likely you are mis-using the API. The return value of SSL_read() and SSL_write() must always be passed through SSL_get_error() to determine if an error such as SSL_ERROR_ZERO_RETURN has been received. There appears to be a problem with OpenSSL when used with non-blocking I/O on Linux. (Running SuSE 6.0, Linux kernel 2.2.5.) A similar situation seems to be happening on NT as well. The code doesn't seem to detect that a socket has been closed by the remote end. Read loops tend to execute a huge number of times in this case, always returning 0 bytes of data. I haven't figured out how/why the loop ever terminates, but in normal situations, it eventually does. In one case in particular in the OpenLDAP slapd (developer snapshot) if a session is just being started, and SSL_accept fails, slapd will loop forever, retrying the SSL_accept. (This assumes the slapd is configured to require a user certificate. The error can be reproduced by using a client without a user certificate to connect to the slapd.) In slapd the I/O loop is structured around a select(). As you know, select will return "readable" for a socket that was closed, and a read on this socket will return 0 bytes to indicate EOF. Unfortunately, it appears that the SSL library doesn't do anything special when a read returns 0 bytes. In particular, the SSL session handle's rwstate variable remains set to SSL_READING in this case, and the upper levels treat this as "a read was incomplete and should be retried." Of course, none of the retries will ever succeed, and so you have a fine infinite loop. This message is going to both the OpenSSL and the OpenLDAP crew because I haven't figured out yet who's doing the wrong thing. This infinite loop may be caused by the ldap_pvt_tls_accept that we wrap around SSL_accept. The large number of loops even in the successful case seems to be a more general problem. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Windows Sockets
Remo Inverardi [EMAIL PROTECTED]: [...] windows sockets [...] blocking or non-blocking? The SSL library can work with both blocking and non-blocking socket I/O; this should be basically the same on NT as on Unix. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Checking for memory leaks
Remo Inverardi [EMAIL PROTECTED]: With OpenSSL 0.9.4, Visual C++ reports memory leaks even if I only use these two lines of OpenSSL code: SSL_CTX *ctx = SSL_CTX_new(SSLv2_server_method()); SSL_CTX_free(ctx); Question is: do I have to free anything else manually or is the leak caused by a OpenSSL "bug". At the end of a program, always delete OpenSSL's per-thread error queue by calling ERR_remove_state(0) (0 means the current thread). Under Windows, if you use multiple threads, each thread that exits will automatically have its error queue deleted, but presumably your memory-leak checking takes place before the main thread has exited. The reason that you get an error message from SSL_CTX_new (and ctx == NULL) in your example is that you did not load the algorithms by calling SSLeay_add_ssl_algorithms(). (You probably also want to load the error strings so that you won't have to decipher numerical OpenSSL error codes manually: call ERR_load_crypto_strings() and SSL_load_error_strings()). Before the program exits, call EVP_cleanup() and ERR_free_strings() to free the memory allocated in these steps. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
