Database ( 'FileSize' * 'PageSize' = 840M ) function in "memory-constrained environments": Windows 7 32-bit & 4G RAM:
After the upgrade to 4178, we started getting the following errors:
Unfortunately, changing server option (from -c 15% to -cl 700M & -ch 1G) and unload/reload database do not resolve the errors.
Does this mean a "memory leak" in 4178?
19.08.2015 - 17:57:39 CET - Info for Customer by SAP
I don't recognize this pattern myself. If this information does not help do open up a support call to help drill into this deeper.
One factor to be aware of is that the encryption libraries changed from Certicom to OpenSSL between those builds. So, this issue could be related to the conditions on that machine in relationship with the latter library. But it is hard to ascribe that assertion to this scenario.
Is this constant error for all connection attempts? Intermittent? Just rare?
FWIW If this turns out to be just an issue with encrypted connections, you should be able to run unencrypted or with just simple encryption until this is resolved.
The assertion itself is not so much a leak but related to address map allocation. It is related to an attempt access a large contiguous block of addresses (which itself makes less sense). How that is being caused by a new connection attempt is not so clear.
Given it is a TLS handshake error, we do sometimes see a few issues with stale/incompatible certificates that Certicom would pass but no longer fly with OpenSSL. I would look there next myself; starting with the newer ViewCert utilty. A number of older certificates that used to just work with Certicom are not current/compliant enough to work with OpenSSL. Look for some of the changes introduced Strong encryption in FIPS, TLS, and HTTPS now achieved using OpenSSL as well as the KBA on a known pattern "TLS handshake failure" or "Server certificate not trusted"
Best of luck
answered 30 Jul '15, 12:26
Nick Elson S...
I guess there is always a chance you are hitting a vulnerability CVE-2015-0205
According to the OpenSSL site "... A memory leak can occur in . . . under certain conditions. . . . The memory leak could be exploited by an attacker in a Denial of Service attack through memory exhaustion. ... " •Fixed in OpenSSL 1.0.1k
We started shipping EBFs / SPs with OpenSSL 1.0.1k (or higher) for Windows as of EBF#4183 / SP82; so you should retest with one of those.
I don't believe you have described a vulnerability to this ... but I am also uncertain if your -xs logging would show such a denial of service attack if you are exposed to that possibility.
... but again ... if this does not help we would need to reproduce this happening
answered 18 Aug '15, 21:20
Nick Elson S...