Nitin M wrote:
Darryl, What is your opinion on this finding? As you were also keen on
knowing the result of this experimentation. :)
What is you opinion?
Here is the valgrind output for the above program for your reference.
==10877== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17
From: Darryl Miles [EMAIL PROTECTED]
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org
Subject: Re: Memory Leaks in SSL_Library_init()
Date: Mon, 02 Apr 2007 18:56:40 +0100
Nitin M wrote:
Darryl, What is your opinion on this finding? As you were also keen on
knowing the result
on
knowing the result of this experimentation. :)
Thanks in advance
regards
-Nitin
From: Nitin M [EMAIL PROTECTED]
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org
CC: [EMAIL PROTECTED]
Subject: Re: Memory Leaks in SSL_Library_init()
Date: Wed, 28 Mar 2007 04:14:17 +
1
Richard Salz:
Suppose another thread does this:
*p=99;
*p=98;
Out of scope -- the C standard does not define ANY semantics for
multiple
threads of execution.
Exactly. The original example was:
extern volatile char* p;
int i, j;
i = *p;
j = *p;
On 3/28/07, Darryl Miles [EMAIL PROTECTED] wrote:
Actually 'volatile' doesn't provide a useful fix.
[...]
The problem occurs after the beginning of the function. If the compare is
done on a cached copy in a register. Look at this example:
if (variable!=NULL)
{
free(variable);
This is the precise optimization that 'volatile' inhibits.
For single-threaded code, you are right. But we are talking about
multi-threaded code.
'volatile'
requires that the value not be cached in cheap-to-access locations
like registers, instead being re-loaded from expensive-to-access
If you have multiple threads accessing it, you manage access using a
mutex. If locking is important to the application that it's in.
(Clearing the compression is as important as clearing the library
state. If there's a lock around the library state clearing, a lock
needs to exist around the
A read of a 'volatile uint64_t', btw, is supposed to make sure that it
reads from the original memory locations, not cached copies of it in
register or spread across multiple registers.
Which it doesn't do on any platform I know of. On every platform, 'volatile'
reads through the caches and
A read of a 'volatile uint64_t', btw, is supposed to make sure that it
reads from the original memory locations, not cached copies of it in
register or spread across multiple registers.
No. The computing model in ANSI/ISO C doesn't really go below the level
of source code.
Volatile only
Kyle Hamilton wrote:
On 3/28/07, Darryl Miles [EMAIL PROTECTED] wrote:
The problem occurs after the beginning of the function. If the
compare is
done on a cached copy in a register. Look at this example:
if (variable!=NULL)
{
free(variable);
variable=NULL;
}
This could easily be
This is the precise optimization that 'volatile' inhibits. 'volatile'
requires that the value not be cached in cheap-to-access locations
like registers, instead being re-loaded from expensive-to-access
locations like the original memory -- because it may be changed from
outside the
Richard Salz wrote:
This is the precise optimization that 'volatile' inhibits. 'volatile'
requires that the value not be cached in cheap-to-access locations
like registers, instead being re-loaded from expensive-to-access
locations like the original memory -- because it may be changed from
Darryl Mile wrote:
A compiler will not generate a store instruction to put back a
cached_copy into the variable location. Principally because there was
no assignment operation in the original code and because even a
non-optimizing compiler knows it can just dump the cached_copy
I was not commenting on any part of the message that I didn't quote. :)
Kyle's claim about things like cache's and registers is wrong, not even
sort-of right. The standard talks about only in terms of sequence points,
and volatile limits what can be done in terms of sequence points. So
Richard Salz wrote:
Kyle's claim about things like cache's and registers is wrong, not even
sort-of right. The standard talks about only in terms of
sequence points,
and volatile limits what can be done in terms of sequence points. So
extern volatile char* p;
int i, j;
Suppose another thread does this:
*p=99;
*p=98;
Out of scope -- the C standard does not define ANY semantics for multiple
threads of execution.
The standard is discussed in terms of an abstract machine and the
machine
the code is running on may bear only as much resemblance to the
Kyle Hamilton wrote:
Oh. I'm sorry. Someone needs to use a keyword 'volatile'.
Bingo. Problem solved on the improper optimization issue.
Actually 'volatile' doesn't provide a useful fix.
Ignoring the fact there is no problem with any CPU that currently
exists. The volatile is most
So the point you are trying to make is, while the function would
solve the
purpose of freeing the compression methods, However the lock are
not really
required in the usage secnario of this function?
If the usage scenario is solely final shutdown of the library, then the lock
is not
David seems to be thinking ahead into the realms of CPUs that have not
been invented yet.
Exactly. That's why there are standards and guarantees. If you follow the
standards and rely on the guarantees you have, your code will work on all
future platforms that provide those same guarantees
From: Darryl Miles [EMAIL PROTECTED]
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org
Subject: Re: Memory Leaks in SSL_Library_init()
Date: Wed, 21 Mar 2007 11:12:38 +
Nitin M wrote:
Does this mean that in such scenario the application need not call
SSL_library_init since
1287 void SSL_free_comp_methods(void)
1288 {
1289 if (ssl_comp_methods == NULL)
1290 return;
1291 CRYPTO_w_lock(CRYPTO_LOCK_SSL);
1292 if (ssl_comp_methods != NULL)
1293 {
1294 sk_SSL_COMP_pop_free(ssl_comp_methods,CRYPTO_free);
David Schwartz wrote:
1287 void SSL_free_comp_methods(void)
1288 {
1289 if (ssl_comp_methods == NULL)
1290 return;
1291 CRYPTO_w_lock(CRYPTO_LOCK_SSL);
1292 if (ssl_comp_methods != NULL)
1293 {
1294
Nitin M wrote:
I wrote a simple program like this to find out the possibility of a
memory leak. The program goes like this.
#includeopenssl/ssl.h
int main()
{
SSL_library_init();
EVP_cleanup();
}
when I run this programm through the valgrind I get the following output.
Ok, it is not
: 0 bytes in 0 blocks.
==10877==possibly lost: 0 bytes in 0 blocks.
==10877==still reachable: 36 bytes in 2 blocks.
==10877== suppressed: 0 bytes in 0 blocks.
From: Darryl Miles [EMAIL PROTECTED]
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org
Subject: Re: Memory
For POSIX threads, the result of reading a variable in one
thread while it
might be modified in another thread is undefined. Line 1289 and
1290 should
be removed.
Not this old chestnut again.
Like it or not, it's a fact.
I can't name a CPU in which an aligned load/store of a
Oh. I'm sorry. Someone needs to use a keyword 'volatile'.
Bingo. Problem solved on the improper optimization issue.
Can we commit the patch so that we don't have to keep getting hit by 2
or 3 threads about valgrind complaining about reachable pointers at
the end of program execution every
Oh. I'm sorry. Someone needs to use a keyword 'volatile'.
Sorry, doesn't help.
Bingo. Problem solved on the improper optimization issue.
What specification says that 'volatile' causes any particular semantics across
threads? I must not have read that one. The 'volatile' keyword is only
@openssl.org
Subject: RE: Memory Leaks in SSL_Library_init()
Date: Tue, 27 Mar 2007 21:23:45 -0700
For POSIX threads, the result of reading a variable in one
thread while it
might be modified in another thread is undefined. Line 1289 and
1290 should
be removed.
Not this old chestnut
Hi!
I have an example case where by the unused memoy allocated by
SSL_library_init when not freed, would accumulate.
There is an application which takes services from some of the
libraries say
A, B and C.
These libraries are dynamically loaded and unloaded into the
application as
and
: Memory Leaks in SSL_Library_init()
Date: Wed, 21 Mar 2007 00:14:53 -0700
Hi!
I have an example case where by the unused memoy allocated by
SSL_library_init when not freed, would accumulate.
There is an application which takes services from some of the
libraries say
A, B and C
?
regards
-Nitin
From: David Schwartz [EMAIL PROTECTED]
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org
Subject: RE: Memory Leaks in SSL_Library_init()
Date: Wed, 21 Mar 2007 00:14:53 -0700
Hi!
I have an example case where by the unused memoy allocated by
SSL_library_init when
HI!
Thanks again for highlighting those issues. What would be the
best way for
the application using those pluggins to avoid this issue of
SSL_library_init()?
There are really two good ways that ensure that all problems are resolved.
Other ways just deal with problems as they crop up and
If we say that the call SSL_library_init() would initialze some data
structures which have process scope and are initialized only once.
In such case what is the problem in having a *single* function
which exacly
cleans up those data structures at the time of process termination?
See my
Nitin M wrote:
Does this mean that in such scenario the application need not call
SSL_library_init since it does not need those extra initialisations and
can achieve only the required initialisations with specific calls?
If this is true I have two more questions here,
1. In what scenario
Is it required to call SSL_library_init() if I only want to use some crypto
functionalities?
-Nitin
From: Darryl Miles [EMAIL PROTECTED]
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org
Subject: Re: Memory Leaks in SSL_Library_init()
Date: Wed, 21 Mar 2007 11:12:38 +
Nitin
Is it required to call SSL_library_init() if I only want to use
some crypto
functionalities?
All SSL_library_init does is add ciphers and digests to the EVP table. If
you don't need any ciphers and digests accessible through the EVP interface
or you add those ciphers and digests yourself, you
Hi!
for using valgrind this way of configuring is OK
./config --prefix=/home/user -DPURIFY
or this is required
./config --prefix=/home/user -DPURIFY -ggdb
regards
-Nitin
From: Darryl Miles [EMAIL PROTECTED]
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org
Subject: Re: Memory
David Schwartz wrote:
The function SSL_library_init() is observed to be introudcing
memory leak in
the application code. There is still some amount of memory leak left even
after the series of cleanup calls suggested in the openssl FAQ.
Your first sentence is pretty funny though. How can
David Schwartz wrote:
The function SSL_library_init() is observed to be introudcing
memory leak in
the application code. There is still some amount of memory leak left even
after the series of cleanup calls suggested in the openssl FAQ.
Can someone help understand that technically what is the
From: David Schwartz [EMAIL PROTECTED]
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org
Subject: RE: Memory Leaks in SSL_Library_init()
Date: Tue, 20 Mar 2007 05:02:01 -0700
The function SSL_library_init() is observed to be introudcing
memory leak in
the application code
Keepin it apart from the memory leak, i would like to know by
example how a
perfect cleanup can casue performance problems?
One common case goes like this:
1) You have an object you create very early in the library initialization.
2) The object is accessed a lot, and having to check if it's
Hi! All,
Thanks very much for your inouts on this.
From: Darryl Miles [EMAIL PROTECTED]
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org
Subject: Re: Memory Leaks in SSL_Library_init()
Date: Tue, 20 Mar 2007 17:18:40 +
David Schwartz wrote:
The function SSL_library_init
() would get
called.
regards
-Nitin
From: David Schwartz [EMAIL PROTECTED]
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org
Subject: RE: Memory Leaks in SSL_Library_init()
Date: Tue, 20 Mar 2007 05:02:01 -0700
The function SSL_library_init() is observed to be introudcing
memory leak
If Open-SSL does not already do this, they should add code for memory pools.
On Wed, May 26, 2004 at 03:15:36PM -0400, [EMAIL PROTECTED] wrote:
How do you read the debug output of CRYPTO_MDEBUG?
Why is there so many 87389 bytes leaked in 1881 chunks?
After making three connections all of
Yes, you've misinterpreted the output. I added up all of the number=
fields and got 899. I'm guessing that you added up the first number on each
line. That number represents the order of the allocations.
Regards,
Steven
-Original Message-
From: Gleison Santos [mailto:[EMAIL
CRYPTO_malloc() in .\crypto\mem.c
ERR_get_state() in .\crypto\err.c
ERR_clear_error() in .\crypto\err.c
ASN1_d2i_bio()in .\crypto\asn1\a_d2i_fp.c
d2iX509_CRL_bio() in .\crypto\x509\x_all.c
main()
mainCRTStartup()
Okay, I think I figured out what is going on. It actually had nothing to do
with ssl. I apologize for taking up time of the people of this list on an
issue that turned out not to be related to the list. I do appreciate all the
help I have received here. Through the ideas presented by those of you
On Wed, Apr 04, 2001 at 09:23:26AM -0500, Brook A. Keele wrote:
[...]OpenSSL built fine, I can make the connection, most of the
time, but after a short while I have to close the server because I am out of
memory. These memory leaks in CRYPTO_malloc are baffling me. Anyone who can
Title: RE: Memory Leaks
Following calls should reduce the memory leaks
ERR_free_strings();
ERR_remove_state(0);
EVP_cleanup();
CRYPTO_mem_leaks(bio_err);
sachin
-Original Message-
From: Brook A. Keele [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 04, 2001 7:23 AM
Well,
It doesn't look like there is any memory leaks in the CRYPTO library. It appears
it is all in my code. I am having a really big problem finding it though. My
code was multithreaded. I didn't know if there were any issues with
multithreading in openssl so I got rid of it and made it
Dror wrote:
The disadvantages (in VC environment) are:
1.) that the memory leaks report appears in two places: the leaks
occurred in the application (with the file name and line number)
together with those occurred in OpenSSL (without the file name
and line number ) on the debug output
From: "Dror" [EMAIL PROTECTED]
drorotmi The functions interface (defined in crtdbg.h) is as follow:
drorotmi void *_malloc_dbg( size_t size, int blockType, const char *filename,
drorotmi int linenumber );
drorotmi void *_realloc_dbg( void *userData, size_t newSize, int blockType,
drorotmi const
Oh, I see what you mean, those are so to say replacements for malloc()
and friends... Hmm... Actually, this is doable through yet another
call level, but it also adds another level of complication.
Precisely.
Dror,
I've made a change that allows for the kind of functionality you
requested. It will be available in tonights snapshot, or if you want
to rsync it immediately...
The requirements for you will be to add the following code to your
application (and remove the CRYPTO_set_mem_debug_functions()
And do what with it? It would become some kind of OpenSSLish value
You're right, I misinterpreted your previous answer.
I'll check it as soon as I can fetch it and will inform you.
TAL
Dror
__
OpenSSL Project
On Mon, Nov 13, 2000 at 04:22:29PM +0530, Shridhar Bhat wrote:
I have written a server which receives connections from
SSL clients. I accept SSL connections as well as read the
data from the client in the following function: DoSSLRead.
Upon the arrival of the client connection, the
Bodo Moeller wrote:
On Wed, Nov 08, 2000 at 02:22:06PM +0530, Shridhar Bhat wrote:
I have written a server which receives connections from
SSL clients. I accept SSL connections as well as read the
data from the client in the following function: DoSSLRead.
Upon the arrival of the
Shridhar Bhat wrote:
I have written a server which receives connections from
SSL clients. I accept SSL connections as well as read the
data from the client in the following function: DoSSLRead.
Upon the arrival of the client connection, the SSL_read()
is called 3 times (2 times for handshake
On Wed, Nov 08, 2000 at 02:22:06PM +0530, Shridhar Bhat wrote:
I have written a server which receives connections from
SSL clients. I accept SSL connections as well as read the
data from the client in the following function: DoSSLRead.
Upon the arrival of the client connection, the
On 29 Apr 00, at 18:54, [EMAIL PROTECTED] wrote:
add: lh_free((LHASH*)ERR_get_err_state_table());
at the end of the cleanup.
Dror
VC6.0 detected memory leaks in the following code! And the code do
only PEM_read_bio_PrivateKey()!!
When I enabled the OpenSSL_add_ssl_algorithms() and
Message -
From: Richard Levitte - VMS Whacker [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, March 15, 2000 5:15 PM
Subject: Re: memory leaks in SSLeay_add_all_algorithms?
dykiel Hello, the simple piece of code below results in "4243 bytes
leaked in 280 c
Richard Levitte - VMS Whacker [EMAIL PROTECTED]:
Might be a good idea...
From: "Richard Dykiel" [EMAIL PROTECTED]
To: "Richard Levitte - VMS Whacker" [EMAIL PROTECTED]
A suggestion however?
Not a top priority, but it would be nice to clean up these leaks, [...]
There are no known
gic [EMAIL PROTECTED]:
I was developing an SSL client (with openssl-0.9.3a)
and found memory leaks when using RC4-MD5 (1024/128 bits).
HOWEVER, when I switched to "EXP-RC4-MD5" (512/40 bits),
there are NO leaks.
The best way to reproduce the leaks is to run 's_time'
for a long time. (Use
63 matches
Mail list logo
