There is no planned update that I am aware of but you can certainly update your own version. The openssl website lists sites where openssl can be downlooaded (usually for windows).
On the issue of crashes, the current version works well for 99.9% of the people and where there has been problems, using the very latest version did not help.
When did openssl switch to cdecl?
In the middle of 2006, I did some work for a customer who wanted the latest SSL for windows. I downloaded it and installed it.
It worked with no issues except that the initialization was different.
13. I think I've detected a memory leak, is this a bug?
In most cases the cause of an apparent memory leak is an OpenSSL internal table that is allocated when an application starts up. Since such tables do not grow in size over time they are harmless.
These internal tables can be freed up when an application closes using various functions. Currently these include following:
Thread-local cleanup functions:
Application-global cleanup functions that are aware of usage (and therefore thread-safe):
ENGINE_cleanup() and CONF_modules_unload()
"Brutal" (thread-unsafe) Application-global cleanup functions:
ERR_free_strings(), EVP_cleanup() and CRYPTO_cleanup_all_ex_data().
Subject: Re: [openssl.org #1802] Bug report: Persistent memory leak that cannot be freed
Date: Tue, 6 Jan 2009 15:39:45 -0800
From: "Huzaifa Al Nahas" <email@example.com>
Let me give me more details about this issue. I am using another
library libcurl that uses openssl. After initialization and proper
cleanup of CURL handles, I detect this memory leak. I contacted
libcurl developers and they suggested that libcrypto is doing some
global initializations (that include calling ENGINE_new) as the
previous post shows. However, libcrypto seems to be not cleaning up
after itself. A solution to this issue could be by having libcurl
developers call a global cleanup function of libcrypto in their
cleanup functions. Does such a function that cleans up the global
memory allocations done in libcrypto exist?
Therefore you have delivered an application to your customer with a potential memory leak
tstalzer wrote:Well-- then we belong to the 0,1% rest.....
wembley wrote:I can assure you that you are not in a group making up 0.1% of the VA Smalltalk OpenSSL users. I can't say what percentage of users are having similar problem to yours since we don't have a count of how many customers are using OpenSSL with VA Smalltalk, but it is substantial. We realize that this is a serious problem -- that is why we have expended significant effort in trying to solve the problem.
At this point we have provided a workaround to those customers with this particular issue, but it is just a workaround. This workaround reduces the frequency of occurrences, but does not eliminate them.
We continue to work on the underlying problem and we will report here when it is eventually solved.
We need to provide https services in our web application (portal). However we had a couple of crashes (memory issues) using the current openssl interface. We integrated also the patch from Solveig in changing the access from async to sync. The patch made the application "usable" however I it didn't fix all the issues (we still got occasional memory access problems, especially in load test szenarios).
Looking into the DLL's, I saw that the Version 0.9.6g from Aug, 2002 is integrated. Is there an update planned for the VA/ST 8 Version in order to use a more current version of openSSL?
Users browsing this forum: Yahoo [Bot] and 1 guest