SQL Anywhere 12.0.1.4178 vs 3537: memory leak?

[former_SQLA_member326303]

Database ( 'FileSize' * 'PageSize' = 840M ) function in "memory-constrained environments": Windows 7 32-bit & 4G RAM:

 Running Windows 7 Build 7601 Service Pack 1 on X86 (X86_64)
 Server built for X86 processor architecture
 302264K of memory used for caching
 Minimum cache size: 302264K, maximum cache size: 1401936K
 Using a maximum page size of 8192 bytes
 Multiprogramming level: minimum:4, current:20, maximum:80
 Automatic tuning of multiprogramming level is enabled
 TCP using Winsock version 2.2
 IPv6 support enabled

After the upgrade to 4178, we started getting the following errors:

 Assertion failed: 101413 (12.0.1.4178)[d4w] Unable to allocate a multi-page block of memory
 The TLS handshake failed, error code 8
 Error creating new connection: hcommblk.Open (8)
 Shared Memory function newConn failed 

Unfortunately, changing server option (from -c 15% to -cl 700M & -ch 1G) and unload/reload database do not resolve the errors.
When we return to 3537 (with -c 15%) errors disappeared.

Does this mean a "memory leak" in 4178?

[former_SQLA_member326303 · Accepted solution]

19.08.2015 - 17:57:39 CET - Info for Customer by SAP
Hi Ilia,
We have fixed a memory leak as part of CR #788402 in 12.0.1.4310 and 16.0.1.2173 (this is the reference number you will find in the readme file that ships with each patch): "When calling a secure web procedure, the database server would leak memory. This has been fixed"...

[Breck_Carter · Accepted solution]

12.0.1.4310

Is that supposed to be 12.0.1.4301? ...I only ask because 12.0.1.4301 just got released, and because...

16.0.1.2173

...will not ever exist (there will never, ever, be a 16.0.1.anything 🙂

[VolkerBarth · Accepted solution]

12.0.1.4301 does not contain such a CR fix (or at least it is not contained in the EBF readme), and the binaries are from 2015-07-31, so this seems to be a newer fix and 12.0.1.4310 seems reasonable.

FWIW, the according CR note lists an empty entry in the (old) Sybase CR system - in my experience, these entries are still used/filled generally.

[Breck_Carter · Accepted solution]

Makes sense... so the reference to 16.0.1 is just a typo and not a sign of deeper confusion 🙂

Don't you wish that all references to future build numbers would come with a disclaimer to that effect? i.e. "don't bother to go hunting for 12.0.1.4310 because it ain't there yet".

...ah, heck, we're just steenking end users, our time don't mean nuthin 🙂

[former_SQLA_member326303 · Accepted solution]

For EBF 25376: 16.0 SP42 Build 2178 13.10.2015 - OK (No memory leaks)

[VolkerBarth · Accepted solution]

So feel free to accept your answer as "accepted":)

[former_SQLA_member326303 · Accepted solution]

I'm waiting for ASA12...

[VolkerBarth · Accepted solution]

FWIW, 12.0.1.4314 for Windows x86 has been released on 2015-10-23:)

[former_SQLA_member326303 · Accepted solution]

For EBF 25390: 12.0.1 SP95 Build 4314 23.10.2015 - OK: No memory leaks 🙂

[Former Member]

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

[former_SQLA_member326303]

Error occurs approximately once a day.
Then, it is reproduced with each new HTTPS-request. For example:

I. 07/27 23:04:34. Finished checkpoint of "d4w" (D4w.db) at Mon Jul 27 2015 23:04
E. 07/27 23:13:00. The TLS handshake failed, error code 8
...
I. 07/27 23:18:01. Starting checkpoint of "d4w" (D4w.db) at Mon Jul 27 2015 23:18
I. 07/27 23:18:01. Finished checkpoint of "d4w" (D4w.db) at Mon Jul 27 2015 23:18
E. 07/27 23:19:00. The TLS handshake failed, error code 8
...

From the point of view of ASA12 error is as follows:

[connid = 26, 07/23 17:13:02.995, REQUEST]
POST /d4w/api/getPeriod HTTP/1.0
Host: centaurportal.com
ASA-Id: 5831d8ab74f348758f1bb69451cbccbf
Accept-Charset: windows-1251, UTF-8, 
Authorization: Basic M...c=
Content-Length: 158
Connection: close
Date: Thu, 23 Jul 2015 07:13:03 GMT
User-Agent: SQLAnywhere/12.0.1.4178
Content-Type: application/xml; charset=windows-1251
<slotRequest>...</slotRequest>
[connid = 26, 07/23 17:13:03.151, RESPONSE]
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Thu, 23 Jul 2015 07:13:26 GMT
Content-Type: application/xml;charset=UTF-8
Connection: close
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><response>...</response>
[connid = 26, socket closed by peer]
[connid = 26, socket closed]
[connid = 26, 07/23 17:13:03.192, REQUEST]
POST /d4w/api/getPeriod HTTP/1.0
Host: centaurportal.com
Accept-Charset: windows-1251, UTF-8, 
Connection: close
Content-Type: application/xml; charset=windows-1251
Date: Thu, 23 Jul 2015 07:13:04 GMT
ASA-Id: 5831d8ab74f348758f1bb69451cbccbf
Content-Length: 158
Authorization: Basic M...c=
User-Agent: SQLAnywhere/12.0.1.4178
[connid = 26, Error: socket closed]
[connid = 26, socket closed]
[connid = 26, Error: socket closed by peer]

[former_SQLA_member326303]

Use certificate chain:

SQL Anywhere X.509 Certificate Viewer Version 12.0.1.4178
X.509 Certificate
Common Name:             *.centaurportal.com
Organizational Unit:     Domain Control Validated
Issuer:                  Starfield Secure Certificate Authority - G2
Serial Number:           4e6f781e4a8589bf
Issued:                  Jan 16, 2015   0:56:38
Expires:                 Jan 16, 2016   0:56:38
Signature Algorithm:     RSA, SHA256
Key Type:                RSA
Key Size:                2048 bits
Basic Constraints:       Is not a certificate authority
Key Usage:               Digital Signature, Key Encipherment
X.509 Certificate
Common Name:             Starfield Secure Certificate Authority - G2
Country Code:            US
State/Province:          Arizona
Locality:                Scottsdale
Organization:            Starfield Technologies, Inc.
Organizational Unit:     http://certs.starfieldtech.com/repository/
Issuer:                  Starfield Root Certificate Authority - G2
Serial Number:           7
Issued:                  May 3, 2011  10:00:00
Expires:                 May 3, 2031  10:00:00
Signature Algorithm:     RSA, SHA256
Key Type:                RSA
Key Size:                2048 bits
Basic Constraints:       Is a certificate authority, path length limit: 0
Key Usage:               Certificate Signing, CRL Signing
X.509 Certificate
Common Name:             Starfield Root Certificate Authority - G2
Country Code:            US
State/Province:          Arizona
Locality:                Scottsdale
Organization:            Starfield Technologies, Inc.
Issuer:                  Starfield Root Certificate Authority - G2
Serial Number:           0
Issued:                  Sep 1, 2009   3:00:00
Expires:                 Jan 2, 2038   2:59:59
Signature Algorithm:     RSA, SHA256
Key Type:                RSA
Key Size:                2048 bits
Basic Constraints:       Is a certificate authority, path length limit: 0
Key Usage:               Certificate Signing, CRL Signing
Do you need more information?  
Best regards

[former_SQLA_member326303]

I would like to clarify once again:
- HTTPS-Request with 'Certificate Signing, CRL Signing'-certificate done many times (~1000).
- Suddenly there is 'The TLS handshake failed, error code 8'-error.
- Error is repeated for every request until the ASA12-server is rebooted.
- After rebooting the ASA12-server requests are "error-free" again...

Error occurs approximately once a day.
The certificate remains unchanged.

[former_SQLA_member326303]

To test the hypothesis about memory leaks I use Resource Monitor.
I performed 3,600 HTTPS-requests.
At the same time the working set:
for 12.0.1.4178 increased by approximately 20,000 K,
for 12.0.1.3537 has not changed.

[Former Member]

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