SAP SQL Anywhere

Question

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?

Accepted Answer

3

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"...

permanent link

answered 25 Aug '15, 12:38

Ilia63
1.2k●51●57●82
accept rate: 44%

converted 25 Aug '15, 16:41

Volker Barth
40.2k●361●549●822

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 :)

(25 Aug '15, 13:51) Breck Carter

Replies hidden

1

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.

(25 Aug '15, 15:54) Volker Barth

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 :)

(25 Aug '15, 16:23) Breck Carter

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

(20 Oct '15, 07:50) Ilia63

Replies hidden

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

(20 Oct '15, 08:07) Volker Barth

1

I'm waiting for ASA12...

(21 Oct '15, 08:04) Ilia63

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

(26 Oct '15, 03:47) Volker Barth

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

(26 Oct '15, 04:29) Ilia63

showing 3 of 8 show all flat view

Answer 2

2

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

permanent link

answered 30 Jul '15, 12:26

Nick Elson S...
7.3k●35●107
accept rate: 32%

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]

(30 Jul '15, 13:01) Ilia63

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

(30 Jul '15, 13:03) Ilia63

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.

(31 Jul '15, 08:31) Ilia63

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.

(13 Aug '15, 12:14) Ilia63

flat view

Answer 3

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

SAP SQL Anywhere

SQL Anywhere 12.0.1.4178 vs 3537: memory leak?

X.509 Certificate

X.509 Certificate

X.509 Certificate

Follow this question

Related questions