Update for openSSL in VAST 8?

[tstalzer]

Hi

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?

--Thomas

[tc]

Hello,

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.

--tc

[tstalzer]

Thanks for the answer

Well-- then we belong to the 0,1% rest.....

So we'll have to see on how we are going to manage this

--Thomas

[marten]

Hello,

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.

--tc

tc,

actually the downloadable version of SSL are usually build for cdecl calling support. That means, that you can not exchange the official builds of SSL with the VAST ones - until you accept, that each call to that library leads to vanishing memory. Remember the thread about calling convention of these libraries ?! http://www.instantiations.com/forum/viewtopic.php?f=12&t=2392 I asked you about these libraries and if these are homemade (stdcall) by Instantiations ...

If the libraries delivered with VAST are not homemade by Instantiations (that means: stdcall) it also means, that using these libraries result into memory leaks .... (not much, but each call on a long term running server task ...)

There were no plans to provide stdcall OpenSSL libraries by default and other persons mentioned problems compiling the whole library for stdcall.

[tc]

Hello,

When did openssl switch to cdecl?

--tc

[marten]

Hello,

When did openssl switch to cdecl?

--tc

I do not know, but I read the newslist of OpenSSL and found messages like:

"
be careful VB requires _stdcall as a calling convention.
and all of Openssl is compiled with _cdecl.
"

"
Try cdecl calling convention.
"

or lines of source code like

"
#if defined(__BORLANDC__)
__stdcall /* __stdcall appears to be the only way to get the name
* decoration right with Borland C. Otherwise it works
* purely incidentally, as we pass no parameters. */
#else
__cdecl
#endif
"

That are just hints ... therefore I asked this question again and again ...

Marten

[tc]

Hello,

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.

--tc

[marten]

Hello,

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.

--tc

Yes, it will work - BUT If you call a c method (defined in cdecl) via stdcall (as VA does), you will loose with each API call a small amount of memory (the total size of parameters you gave to the function). Because VA expects, that the called c function will clean up the stack (stdcall) and the called c function thinks, that the caller will clean up the stack (cdecl). Therefore nobody cleans up the stack. THIS is your memory leak. Therefore my question to you about the calling convention of the OpenSSL libraries under Windows (and I know, that VA can only use the "c" calling convention, which means cdecl under Unix - but stdcall under Windows).

Therefore you have delivered an application to your customer with a potential memory leak - which may be a problem in a long term server task (this will for certain not a real problem in a desktop system, running for one hour or so - memory is there).

Therefore you may notice the disaster if a cdecl call hits a stdcall-function. The function itselfs will clean up the stack and the caller will again clean up the stack - and your stack results in a mess and exceptions will follow.

This problem is also to be considered, if you do a call-in into Smalltalk ...

Even inspecting the dll's will not help, because mostly the programmers are throwing away the parameter decorations of stdcall functions (because then he has not to change the c code of your application program, but only some #defines - if the creator of a used dll decides to swap calling convention).

If the creator of a dll does not mention this in the documentation you might have to disassemble the library to get this information or to do some tests and look at the stack pointer before and after the call.

The default behaviour (even of MS2008) is - as I hope to be right - cdecl. Therefore lots of libraries out there are expecting cdecl calls.

As an example: SQLite library is cdecl, PostgreSQL library is cdecl, freeImage library is stdcall, OORexx library is stdcall. lua interpreter is cdecl, OpenSSL seems to be cdecl.

I know, that all this may perhaps change with V80 - but actually one has to be very precise under Windows how to call external libraries and the newest OpenSSL libraries are needing additional VS2008 Runtime modules to work - or you recompile is without that need.

[tc]

Hello,

I can not answer your conclusions after your study of the code but I find it odd that openssl does not document this and no one reports the problem.
http://www.openssl.org/support/faq.html#PROG13

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:

ERR_remove_state()

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().

http://rt.openssl.org/Ticket/Display.html?id=1802&user=guest&pass=guest

Subject: Re: [openssl.org #1802] Bug report: Persistent memory leak that cannot be freed
Date: Tue, 6 Jan 2009 15:39:45 -0800
To: rt@openssl.org
From: "Huzaifa Al Nahas" <halnahas@gmail.com>

Richard,
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?

Thanks,
Huzaifa

Therefore you have delivered an application to your customer with a potential memory leak

. . . they are not shy about speaking up when there is a problem and no such isssue has been reported. The app is heavily used, a server piece and client piece.

--tc

[marten]

tc,

to answer my own question: after doing some low-level debugging I would say, that the SSL libraries delivered with VASmalltalk seem to be cdecl-convention oriented libraries. The functions within the library do NOT clean up the stack - therefore cdecl - but use a simple "ret" statement.

Regarding the other questions - memory leak or not - well, each reader make up their own mind. Perhaps this is really irrelevant, because VASmalltalk may do some stack management (setting up a new stack ?) stuff before actually doing an external API call and undo the stack management after return and then these missing memory is indeed not relevant. But only the VM developers can answer this question. I really would like to know more about that, because then I could perhaps give up all that work writing wrapper dll's to get rid of that calling-convention mismatch. John ? How the API calling actually done ?



Marten

[wembley]

Well-- then we belong to the 0,1% rest.....

Thomas -

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.

[tstalzer]

Hi John

>>...0.1%...<<
I put a Smiley at the end of the line...

I really appreciate all the efforts of you guys are doing to keep up the high standard of Software quality in the product - I know, it is not easy.

The original question was just about that I noticed, that we have significant problems in our applications since we turned on the SSL Communications. I looked in to the DLL's and noticed that the version being used was some time old (and 6 years is quite some time in Software development) - so I tried the "Windows approach" - maybe we just need to update to the current version to solve some problems.

If there is anything I can to do to help to solve this problem (beta test, provide test cases, help looking into the stuff) please let me know.

--Thomas

[daswartz]

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.

While not directly related to the memory issues discussed above, the version of OpenSSL currently distributed with VAST (0.9.6g) contains several significant security problems which have been fixed in the latest versions. You really should update the version being distributed with VAST.

Doug Swartz

[marten]

Hi

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?

--Thomas

I just did some playing with PostgreSQL and this database delivers its own openSSL library - and calling the main dll from that database server (libpg.dll) failed, because of a mismatch of dll (os error 182). Then I copied the openSSL libraries from PostgreSQL to VA and the stuff is working again.