more time?
Can you build OpenSSL from source including the CAPI engine and then run the
tests again?
Make sure the CAPI engine gets built (e.g. openssl engine command)
I suspect the memory leaks come from there!
I just built it again *without* this option 'enable-capieng' and the memory
leaks
The last patches from this have now been applied so closing this ticket.
Thanks!
Matt
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3198
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe:
INGW32
GCC 6.1.0 32-bit
Memory leaks didn't occur with previous OpenSSL versions using the same
environment.
I'm trying OpenSSL from master now but facing issues with Perl at the
moment. Grrr.
Can you try building it using MinGW/MSYS 32-bit?
Thanks for looking at it.
Cheers.
Ser.
--
openssl-d
> How did you configure/build? What versions of mingw/msys did you use?
./configure mingw --prefix=/mingw
make depend
make all
make test
MSYS 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 unknown; targ=MINGW32
GCC 6.1.0 32-bit
Memory leaks didn't occur with previous OpenSSL versions using the s
/openssl-1.0.2h/test'
make: *** [tests] Error 2
However, if I do make -k test, then I finish without the memory leaks
you saw:
ALL OCSP TESTS SUCCESSFUL
Test X509v3_check_*
../util/shlib_wrap.sh ./v3nametest
../util/shlib_wrap.sh ./heartbeat_test
Test constant time utilites
../util/shlib_wrap.sh
Ciao.
Just built OpenSSL 1.0.2h from source and when running the tests I can see some
memory leaks.
The same did not happen when building previous versions on the same environment
and same command line options.
Thanks in advance.
Find below the last bit of a long long long test output
the code has changed a great deal in the past decade (!!!)
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=684
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe:
On 18/02/16 13:59, Michel wrote:
> Yes !
> With your 2 patches applied, tls_decrypt_ticket.patch and
> fix-win-thread-stop.patch,
> (looks like I lost the first one yesterday),
> none of my tests programs using libSSL v1.1 reports leaks.
>
> I feel better. :-)
Great. I'll get those reviewed
[mailto:openssl-dev-boun...@openssl.org] De la part de Matt
Caswell
Envoyé : jeudi 18 février 2016 13:27
À : openssl-dev@openssl.org
Objet : Re: [openssl-dev] memory leaks detected using libSSL 1.1
On 18/02/16 11:37, Michel wrote:
> Hi Matt,
>
> Here under is the new results after appl
nup_all_ex_data()
> OPENSSL_INIT: OPENSSL_INIT_library_stop: EVP_cleanup()
> OPENSSL_INIT: OPENSSL_INIT_library_stop: CONF_modules_free()
> OPENSSL_INIT: OPENSSL_INIT_library_stop: RAND_cleanup()
> Assertion failed: !bLeak, file p:\mes
> programmes\tests\_testsshared\teststls-11\te
\teststls-11\testtls.cpp, line 165
Detected memory leaks!
Dumping objects ->
{7025} normal block at 0x00A75628, 8 bytes long.
Data: <> 00 00 00 00 01 00 00 00
{5009} normal block at 0x00A3CB88, 12 bytes long.
Data: < 4 > A8 0C A4 00 00 00 00 00 C0 34 01 00
{500
hread.
> Both of them have OPENSSL_thread_stop() in their [pre-]exit member function.
>
> Michel.
>
> -Message d'origine-
> De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Matt
> Caswell
> Envoyé : mercredi 17 février 2016 17:23
> À :
function.
Michel.
-Message d'origine-
De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Matt
Caswell
Envoyé : mercredi 17 février 2016 17:23
À : openssl-dev@openssl.org
Objet : Re: [openssl-dev] memory leaks detected using libSSL 1.1
> Am I missing anything e
t;
> I tried lots of modifications to the 1.1 version in order to understand what
> is happening,
> but the only thing I noticed is leaks occur if at some point the program go
> to the OpenSSL error subsystem,
> like in the 2 reports below.
>
> Can you please help in this matt
of modifications to the 1.1 version in order to understand what
is happening,
but the only thing I noticed is leaks occur if at some point the program go
to the OpenSSL error subsystem,
like in the 2 reports below.
Can you please help in this matter ?
Detected memory leaks!
Dumping objects ->
{7453} nor
an have a look at them.
> I will investigate deeper tomorrow concering 1.0.2.
Are you linking to OpenSSL statically?
Please see the "Notes" section on this page:
https://www.openssl.org/docs/manmaster/crypto/OPENSSL_atexit.html
Matt
>
> Thanks again,
>
> Michel.
>
> D
Hi,
I have multithreaded test programs (client and server) that I use to test
some functionalities build with OpenSSL.
They started to warn about memory leaks when I linked them with version 1.1.
As I had to do some code changes to adapt the new version, I first thought I
forget some [new
On 13/02/16 22:19, Michel wrote:
> Hi,
>
>
>
> I have multithreaded test programs (client and server) that I use to
> test some functionalities build with OpenSSL.
>
> They started to warn about memory leaks when I linked them with version 1.1.
>
> As I had to
,
Michel.
Detected memory leaks!
Dumping objects ->
{4383} normal block at 0x006472C8, 8 bytes long.
Data: <> 00 00 00 00 01 00 00 00
{4381} normal block at 0x00646B48, 12 bytes long.
Data: < od } > D8 6F 64 00 00 00 00 00 20 7D 00 00
{4379} normal block at 0x00647248
This is reported against 0.9.8; please open a new ticket if still a problem
with current releases.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On 10/06/14 21:48, Jonas Maebe via RT wrote:
> On 13/12/13 11:54, The default queue via RT wrote:
>
>> In attachment you can find 7 patches against git master (generated via git
>> format-patch) to fix a number of memory leaks (in case of failures) and
>> missing NULL p
>> Attached is the valgrind-output. It says:
>>34 not-freed blocks
The sample program doesn't clean up everything. Look at the function
apps_shutdown in apps/openssl.c (in master)
___
openssl-dev mailing list
To unsubscribe:
U.Mutlu wrote on 11/23/2015 06:43 AM:
U.Mutlu wrote on 11/23/2015 06:32 AM:
Hi,
running the following example from the openssl wiki site under valgrind
gives many memory-leaks in the underlying library functions:
https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption
Hi,
running the following example from the openssl wiki site under valgrind
gives many memory-leaks in the underlying library functions:
https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption
$ gcc -Wall -O2 test_encdec.c -lcrypto
$ valgrind --tool=memcheck --leak-check=full
U.Mutlu wrote on 11/23/2015 06:32 AM:
Hi,
running the following example from the openssl wiki site under valgrind
gives many memory-leaks in the underlying library functions:
https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption
$ gcc -Wall -O2 test_encdec.c -lcrypto
Typo
created by mistake.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Yes, it looks like these have been fixed; closing.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
The proposed patch is mangled and very hard to read, but I think all proposed
changes have already been committed, or the code has been removed.
So I think this can be closed now.
Cheers
___
openssl-dev mailing list
To unsubscribe:
On Sat, Sep 05, 2015 at 01:49:23pm +, Alessandro Ghedini via RT wrote:
> The proposed patch is mangled and very hard to read, but I think all proposed
> changes have already been committed, or the code has been removed.
>
> So I think this can be closed now.
Ugh, wrong subject... this was
The proposed patch is mangled and very hard to read, but I think all proposed
changes have already been committed, or the code has been removed.
So I think this can be closed now.
Cheers
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
The corresponding GitHub pull request was merged, so this can be closed now.
Cheers
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Hello,
see GitHub pull request at
https://github.com/openssl/openssl/pull/354
which fixes memory leaks on error conditions in X509_add1_reject_object()
and PKCS7_verify().
Cheers
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https
On Wed, Aug 05, 2015 at 11:01:13am +, Alessandro Ghedini via RT wrote:
Hello,
see GitHub pull request at
https://github.com/openssl/openssl/pull/354
which fixes memory leaks on error conditions in X509_add1_reject_object()
and PKCS7_verify().
I also added a couple more patches fixing
Fixed in master and 1.0.2; thanks!
OpenSSL_1_0_2-stable 295c629 RT3856: Fix memory leaks in test code
master 2d54040 RT3856: Fix memory leaks in test code
Author: Russell Webb russell.w...@intel.com
Date: Sat Jun 13 10:35:55 2015 -0400
RT3856: Fix memory leaks in test code
Reviewed-by: Matt
From: Russell Webb russell.w...@intel.com
Several tests were not properly cleaning up everything on
process exit, which prevented 'make test' from succeeding
when running with address sanitizer enabled. Fix the tests
to properly free all resources.
Note that this was found with gcc version 6.0
Hi,
Trying to use the 'SRP' code, I found two kinds of memory leaks in srp_vfy.c
.
1) The first kind was due to bad use of OpenSSL 'stack' code and cumbersome
/ confusing names of structure / functions.
In this case, leaks occurs when loading a verifier file containing 'index'
lines
Hello,
The attached patch fixes some memory leaks that were found via Coverity.
---
Kurt Cancemi
https://www.x64architecture.com
From 3d2c713113545255b61efe433e130078d4cf2e22 Mon Sep 17 00:00:00 2001
From: Kurt Cancemi k...@x64architecture.com
Date: Wed, 27 Aug 2014 20:21:33 -0400
Subject
The attached updated patch fixes a style error.
---
Kurt Cancemi
https://www.x64architecture.com
From d112c3f7b36a60f8af109b90fe5299f7ac049cc6 Mon Sep 17 00:00:00 2001
From: Kurt Cancemi k...@x64architecture.com
Date: Wed, 27 Aug 2014 20:37:45 -0400
Subject: [PATCH] Fix memory leaks
On Thu, Aug 28, 2014 at 03:11:14PM +0200, Kurt Cancemi via RT wrote:
The attached updated patch fixes a style error.
I still have a bunch of other patches like this to go thru, but
did a quick look at this, and at least this looks weird:
--- a/crypto/objects/obj_xref.h
+++
Mon Sep 17 00:00:00 2001
From: Kurt Cancemi k...@x64architecture.com
Date: Thu, 28 Aug 2014 13:48:39 -0400
Subject: [PATCH] Fix memory leaks.
---
crypto/asn1/x_x509a.c| 21 -
crypto/ec/ec_ameth.c | 1 +
crypto/ec/ec_mult.c | 1 +
crypto/ec/ecp_mont.c | 7
It was already fixed in the next release after 1.0.2; see rsalz-monolith branch
in akamai/openssl fork on github. thanks.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
__
OpenSSL Project
On 13/12/13 11:54, The default queue via RT wrote:
In attachment you can find 7 patches against git master (generated via git
format-patch) to fix a number of memory leaks (in case of failures) and
missing NULL pointer checks (generally for malloc results) for source files
under crypto
On Tue, Jun 10, 2014 at 09:48:19PM +0200, Jonas Maebe via RT wrote:
On 13/12/13 11:54, The default queue via RT wrote:
In attachment you can find 7 patches against git master (generated via git
format-patch) to fix a number of memory leaks (in case of failures) and
missing NULL pointer
On 10/06/14 21:59, Kurt Roeckx via RT wrote:
On Tue, Jun 10, 2014 at 09:48:19PM +0200, Jonas Maebe via RT wrote:
On 13/12/13 11:54, The default queue via RT wrote:
In attachment you can find 7 patches against git master (generated via git
format-patch) to fix a number of memory leaks
Hi,
In attachment you can find 7 patches against git master (generated via git
format-patch) to fix a number of memory leaks (in case of failures) and missing
NULL pointer checks (generally for malloc results) for source files under
crypto/asn1. I've tried to follow the coding conventions
On 13 Dec 2013, at 11:54, The default queue via RT wrote:
In attachment you can find 7 patches against git master (generated via git
format-patch) to fix a number of memory leaks (in case of failures) and
missing NULL pointer checks (generally for malloc results) for source files
under
Greetings!
In case of error updating ca database a memory leak occur:
$ openssl ca -config z/caCA/ca.conf -in z/user1/req.pem -batch -notext
... skipped ...
failed to update database
TXT_DB error number 2
[19:00:30] 4957 file=ca.c, line=2199, thread=3074324104, number=28,
address=086466F0
On Mon, 22 Nov 2010 16:52:27 +0100, Alexei Khlebnikov via RT
r...@openssl.org wrote:
I see that the patch was applied fully to branches OpenSSL_0_9_8-stable,
OpenSSL_1_0_0-stable and OpenSSL_1_0_1-stable. But it was applied
incompletely to HEAD. I suggest to apply the attached tiny patch
Hi!
I just want to remind about my little patch. More than 3 months passed
without any activity on it. I'll appreciate if someone looks at it before
OpenSSL code changes so much that the patch becomes non-mergeable. The
patch is quite trivial, shouldn't create any regressions. The patch
Mandatory information:
Request type: PATCH
OS and arch: GNU/Linux on IA-32
OpenSSL version: 1.0.0a
Hi OpenSSL project,
I'd like to submit a patch which includes a handful of small fixes:
1) Out-of-memory error checking.
2) Memory leak fix for OOM situation.
3) Fall-through comment for a case
hi,
we've developed a tool for automatically detecting memory errors. We
ran our tool on openssl and it has detected the following (possible)
memory leaks in
apps/speed.c
function
static int do_multi(int multi)
At line 2759 the variable fds is allocated. But at line 2776 and 2925
Hi,
I suggest some quick patches (memory leaks):
All OS.
All openssl versions.
1) in pk7_smime.c:
255a256
sk_X509_free(signers);
New code:
tmpin = BIO_new_mem_buf(ptr, len);
if (tmpin == NULL)
{
PKCS7err
Hi!
There is a new finding to this. There is one more place for porbable memory
leak. The earlier solution which I proposed(using a funtion
SSL_free_comp_methods) is usfficient to arrest the memory leaks if zlib is
not being dynamically loaded.
if I enable -DZLIB -DZLIB_SHARED in openssl
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
there are users who simply want to use
OpenSSL to provide just a single digest algorithm, and consequentially
don't need all the extra initialization for SSL support.
Out of interest where are those memory leaks that you find ?
As for the series of cleanup calls, there are several reasons. The two main
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
Hi All!
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 problem in
committed (with minor modifications). Please test a recent snapshot.
Thanks,
Nils
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Below is a patch against openssl-0.9.8d.tar.gz to fix some memory leaks in the
pkcs7 functions when errors occur.
Since I am in the US, I have already submitted the patch to the US Bureau of
Industry
and Security and the Encryption Request Coordinator.
Thanks in advance,
Charles
diff -Naur
On Mon, May 16, 2005 at 06:30:26PM +0200, Riaz Rahaman via RT wrote:
I don't see any patch attached?
The message came to the openssl-dev mailing list via the OpenSSL RT2
request tracker. Attachments are not forwarded on this path, but
can be viewed on the web -- in this case:
1 - 100 of 144 matches
Mail list logo
